We are stuck in the tool age.
-Jim Womack (2010)
While attending a lean summit, I asked John Shook if he was frustrated that so many of us had read Managing to Learn (MTL) and became prescriptive about implementing A3 as a tool while virtually ignoring the beautiful interaction he described between the coach and the learner. He just smiled and said “Ahh, we knew it would happen … it was even worse with Learning to See and value stream mapping.”
Still, he felt the management lessons in MTL comprised an important story to tell. In recent years, the lean community has been shifting the conversation away from tool implementation and chasing waste toward focusing on the much more inspiring goal of facilitating collaboration between coaches, learners, and peers. MTL is becoming increasingly relevant as a primer for how we should be talking to each other.
Even Toyota doesn’t put tools at the forefront of lean efforts. When asked about value stream mapping, a manager at Toyota’s Kamigo engine plant said, “the value stream mapping tool you refer to is an analysis technique not widely used here.” If you are attempting to connect disjointed processes into a value stream, this could be a valuable tool. The Kamigo plant was having different problems, so they were using different tools. Do not confuse the solution with the problem you are trying to solve.
So if we don’t start with tools, where do we start? With the “tools” that the manager said were the most widely used at Toyota: “rigorous thinking and problem solving.” Here is a story that shows the difference between these two approaches.
Bob and 5S
Bob Tourney, a Facilities Supervisor at Meritus Health in Hagerstown, MD, began his daily improvement journey with a simple challenge: “I wanted staff to find tools and materials easily without wasting time hunting for them.” Members of his team sometimes had to search three widely separated locations to find their tools.
Rather than just telling his team to “implement 5S,” Bob directed his team to focus on the challenge using the Toyota Kata structure. When we direct 5S implementation for its own sake, we usually have to follow that with a justification – “so people don’t have to look for things.” We are directing a solution, and then stating the problem – whether or not that problem exists in the eyes of the implementer.
In this case, Bob knew he had a problem. What was his solution?
First, Bob thought, “We should probably figure out what tools we actually have, and which ones we should have – what we actually need to do the job.”
Once that was clear, Bob and his team sorted the tools they actually needed and created logical space for storage. They cleaned them up, assigned locations, labeled them, and created a sign-out sheet so they would know where a tool was. That gave them a way to check if the tool should be present, was in-use, or just missing. If the tool was missing, but not signed out, they knew they had a problem, and worked to figure out what happened and correct it.
When Bob and his team started working on this issue, I had predicted our lean office would introduce 5S and other tools to prompt the team to move in the “right” direction, but I was wrong. After they were done, we showed them the formal 5S process. Bob was thrilled: “I realized that my team and I had done what lean professionals call 5S. Using kata, we went through all the stages of 5S and learned along the way!”
Despite the progress, many of our lean practitioners were sorely tempted to direct the team to follow the standard 5S sequence. At one point, one of us even suggested we have a weekend 5S event in the department so that Bob could have some time to “do lean” during the week. Thankfully, we were able to resist the temptation and avoid taking this valuable learning experience away from Bob and his staff. Learning comes from discovering the solution, not from simply following directions.
Improvement starts with challenge
If creating a culture of “rigorous thinking and problem solving” is your ultimate goal, why not follow Toyota’s (and Bob’s) lead and start with a challenge, and challenge yourselves to reach it through daily improvement rather than episodic events?
What kinds of challenges are best for developing rigorous thinking? Hint: if you think copying a specific tool might be a good solution, try to think instead about what problem drove development of that tool. Then give the team a challenge in the form of a specific problem. It is their effort to discover the solution that will facilitate collaborative learning and creative problem solving.
We know Toyota is not “lean” because it uses A3s, 5S, kanban, or any of the other lean tools. These are just the visible outcomes of a premier learning organization. Fortunately, the lean community has had the advantage of being able to ask them.
Toyota’s processes are their current best solutions to their problems, which may or may not be the same as your problems and five-day events are a tool that may or may not create continuous improvement.
For example:
Good | Better |
---|---|
Implement Kanban | Establish 1×1 flow with no delay |
Implement 5S | Able to retrieve tool within X time |
Eliminate waste | Improve lead time from X to Y |
Implement A3s and ensure they are filled out during audits | Structure daily learning sessions between leaders and front-line staff |
Teach scientific dialogue as a habit | Ensure ongoing scientific dialogue |
Whenever we get stuck, Seattle Childrens’ guideline “no harm, no wait” has served us well both inside and outside of the healthcare setting.
The good news for those of us who have been practicing lean for years is that none of the tools are wrong, and they are often very useful. As with value stream mapping at the Kamigo plant, tool implementation is not the goal. A much more inspiring and difficult challenge is to structure our daily interactions in a manner that produces an innovative, collaborative, resilient team capable of tackling any problem the 21st century can throw at them. Best of luck in your respective journeys!
Problem Framing Skills
Improve your ability to break down problems into their specific, actionable parts.
I appreciate this approach, I worked with team that only pushed the tools and with zero learning involved. The results were limited and the production team never embraced the basic concepts.