Through our practice of Lean, we're looking at processes and our management system, looking to identify waste and opportunities for improvement.
Lean is about engaging people to have them ask why we do things a certain way or if things could be better (it's not about finding fault from on high and telling them what to do).
The answer to why we do something a certain way is often:
“We've always done it that way.”
Frontline staff often say that. Managers and executives say it.
The fact we've always done something that way doesn't automatically mean it's a bad practice. But, we should be willing to challenge things to figure out if we should reinvent that process or tweak it. The same question applies not just to the value-adding frontline work, but also to management practices.
Asking why is a powerful Lean practice.
Listen to Mark read this post (and subscribe to the podcast):
Why do we spend a ton of time on annual budgeting? We've always done it that way?
Some organizations challenge that, via the “Beyond Budgeting” movement.
Why do hospitals so easily send nurses home early when census is low? We've always done it that way?
Some organizations challenge that, choosing to engage staff in daily continuous improvement, as paying people to work on improvement can save more money than strictly focusing on reducing labor costs.
As an organization embraces Lean (or as an industry has seen widespread adoption), it's easy for aspects of Lean to become the new “way we've always done it.”
There are some Lean practices that almost become dogma.
I hear it more in manufacturing, but some people advise, in a quite prescriptive way:
“Always start with 5S”
There are plenty of references to this phrase online.
I think a statement like that should really become a question:
“Always start with 5S?”
If somebody makes an absolute statement (look for the words “never” and “always”), you should be able to ask “why?” Why start with 5S?
If the answer is “well, I've always done it that way” or “my sensei taught me that,” we should be willing to challenge the way it's always been done (even if “always” is just a few years).
There might be a good reason why somebody suggests to start with 5S. I wouldn't say “never start with 5S.” 5S can be helpful. But, I think we should be focused less on the question of “what tool should I start with?” and more on the question of what problem we're looking to solve.
I wrote about this a few years back:
Lean in Hospitals: Which Tool or Which Need?
Taiichi Ohno, credited as a creator of the Toyota Production System, said simply in a book:
John Shook, of the Lean Enterprise Institute, asks:
See more about John and the LEI Lean Transformation Model.
Am I being too dogmatic in saying “always start by asking ‘what problem are we trying to solve?'” Maybe.
Either way, if “the way we've always done Lean” is becoming rigid or is no longer helping, we need to ask why… we need to improve. There's a reason Toyota people call TPS the “Thinking Production System.”
We should be thinking. Asking “why?” Challenging things… not just accepting dogma.
Do you see other examples of “Lean dogma” or “the way we've always done Lean” that could be questioned?
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
Good questions. Like any human, we can get stuck in a rut sometimes. I’m reminded of a quote I’ve heard: “Always and never are two words you should always remember never to use.” So to always start with 5S (or with value stream mapping, or anything else) can put us in a corner, or worse, have us acting like the reluctant leaders who don’t want to change. Every situation is unique, and should be looked at uniquely. We may have something we start with 80% of the time, but the 20% deserves a unique look to see that we are adding value.
Great point, Dean. There are repeatable situations (and problems) in life where the same or similar solution or approach might apply. We shouldn’t have to reinvent the wheel each time. We shouldn’t say “every situation is unique” which is no more true than a doctor hiding behind “every patient is unique.” We’re mostly the same.
But, if Lean becomes a form of the dreaded “cookbook medicine” for an organization, that’s bad.
I’m reminded of a conversation I had with a CIO, “we seem to be getting by.” This is just another phrase for “we’ve always done it this way” and certainly opens up another bunch of questions.
I also find that many companies that want to improve on a process, need to know their beginning benchmarks, so many say we need to fix it and have no idea what the beginning process looks like and the transaction #’s.
Thanks for commenting, Brooke.
It’s difficult when people think either:
1) They don’t have to improve
2) They aren’t able to improve
These are huge barriers to change.
“We seem to be getting by” could mean any of those two statements… it’s hard to figure out which, sometimes.
Mark – Great post and questions that you pose. I’ve observed that when people or organizations get too hooked into “this is the way things are done” (could be a process or even the format of a template), they often lose sight of the principles behind the process or tool and get more caught up in the tool for the sake of the tool. This gets back to Shook’s question: “What problem are you trying to solve?”. Perhaps 5S first is the right approach, but without understanding the “why”, it will just become a tool or flavor of the month, and unlikely to impact sustaining change.
Thanks for sharing your thoughts and I agree!
Thanks, Katie.
It also makes me think of ThedaCare’s evolution. Early on, they were told that the way to get Lean was to do lots of Rapid Improvement Events. They eventually learned to work on the management system and the culture too…
Excellent post, Mark.
I see lean dogma in large scale service industries, especially when trying to leverage technology to track lean progress. For example, we have a database site for our associates to submit ideas & problems. One question asks associates to note if the problem came from an A3 or Post-it note (via huddle board). I know life doesn’t work this cleanly. So I often ask myself how a large scale org. can track problems (to share best practices and reduce duplicates) without categorizing associates into believing that lean should always fit into a certain mold.
Why does that matter, the A3 or post-it source, for the sake of improvement?
Mark, great post. There are “Lean dogmas” as you put it that frustrate me because they no longer drive the originally intended behavior. For me, Lean “training” is a big one, the dogma being that you must train the employees and managers in lean concepts and lean tools, and include application time to drive home what they’ve learned. The reason it frustrates me and I believe the originally intended results have been lost is that it perpetuates the idea that learning takes place in a classroom, away from the work. The essence of Lean is infuse learning directly into the work, through experimentation to improve by continuously questioning why things are done they way they are. The moment a person is pulled away from his or her work space, and led into a classroom, that person’s mind is switched into a new mode. The activity becomes categorized as “different than my job” and the ultra critical connection between learning and doing is broken.
Questioning why is so important to learning, as we know. Simon Sinek suggests we start there. I like the parallel to Ohno’s “start with need.” It doesn’t matter that a problem exists and needs to be solved if the people involved do not understand how a solution will fuel progress towards a greater goal; if the problem is solved, the business will prosper, even if only for the next 10 minutes, or 10 weeks. I think that’s where the conversation should start each time.
Thanks, Paul. Yes, I think “start from why” is a better starting point than “start from training” or “start from tool.”
Training people for a day or a week based on what you THINK they will need to know might be an inaccurate prediction. There’s a time and a place for training, perhaps, but many times we overdo it or “overtrain” (things that people forget because they don’t use them right away or never use them).
Mark, I completely agree – we “overtrain” more often than we think. There are some dangers that come along with this, not the least of which is diluting the interest people have in the idea of Lean. Every company is unique, but the Lean principles apply universally. That doesn’t mean the training can be cookie-cutter, template-driven, one-way conversations. I’ve found that getting the students to do most of the talking is a good way to make the best of forced training situations, which requires asking questions about their specific jobs, products, processes. There isn’t a script that works more than once. Do you have a recipe or method you find works for turning a “training condition” into a LEARNING moment?
Having experience working in continuous improvement at a shipyard, I can relate to the phrase, “We’ve always done it that way”. At certain times issues could be blinding but the veterans workers wouldn’t budge because they didn’t believe they needed to. They would bring up phrases such as, “Hundreds of boats have been made this way, why change it now?” and many variations of this expression when the CI workers were tasked in helping make their processes more efficient. I believe that this always needs to be challenged and that “We’ve always done it that way” should never be an excuse for disregarding an issue in a process.
I have never thought about starting each project the same way either like it is mentioned about beginning with a 5S each time in this article. It brings up a good point though, there needs to be a reason why you are starting a CI project with a certain tool and it should not be a monotonous process for each challenge you are trying to resolve. Some projects will require much more in-depth processes and analysis while others wont, and different tools need to be used in each scenario.