LAMDA? PDCA? Improvement Kata? At the Lean Product & Process Development Exchange-North America earlier this fall, Jeff Maling of IBM explained why he set all of these aside to focus his team on the Scientific Method.
All of the problem-solving methods we use within the lean community, though they vary somewhat, arise out of the Scientific Method: make observations, develop a hypothesis, conduct an experiment to test the hypothesis, analyze results, and then decide what to do next.
Jeff and his team used Rapid Learning Cycles to accelerate the development of IBM’s latest smartphone chips. We know Rapid Learning Cycles provide a structure for knowledge creation, which is valuable in and of itself. But Maling reminded us, the cycles of learning turn fastest and are most fruitful when the team has a common framework for solving problems systematically.
In my own work with Rapid Learning Cycles, I use LAMDA (LOOK-ASK-MODEL-DISCUSS-ACT, developed By Dr. Allen Ward of the University of Michigan) for solving product development problems. But Jeff’s team already knew the Scientific Method, so Jeff decided that this would be his team’s problem solving method. The Scientific Method worked well for his team because it helped them think like the scientists they already are.
Chip manufacturing is a complex multi-stage process. When the team wants to make a change to the chip design or the process, they determine what change they want to make, and where in the process to make it. The rest of the process stays the same. Then the production team makes some test chips by changing only the step in the process the engineering group tells them to change. Finally, the testing group pulls the finished chips and tests them alongside unchanged chips to see if the change made a difference or had any unintended side effects. Lean coaches and practitioners might call this PDCA, but it was natural for Jeff’s team to think of this knowledge creation process as “a series of controlled experiments.”
This Scientific Method approach (and language) built upon a framework Jeff’s colleagues had learned as far back as grade school, so there was no learning curve. It emphasizes the importance of having a good hypothesis and good experimental design. This was important for Jeff’s team because they knew they needed to be able to track the effect of small changes on chip performance. They might make a change early in the manufacturing process and need to wait for the rest of the process to see if the change had any effect. For Jeff’s team, lean thinking was about “knowing what you need to learn and how you are going to learn it,” so that they didn’t waste time running experiments that weren’t well-designed, added no real value, or were inconclusive.
Jeff’s story shows why we need alternative ways of talking about problem-solving. While many methods have the same roots, they emphasize different things that are important in different circumstances. Allen Ward developed LAMDA to support problem solving in the context of product development. It emphasizes root cause analysis, which product developers often forget to do, and modeling, which is especially helpful for problems that arise with products that have never been made. Mike Rother developed the Improvement Kata to emphasize the habit of good problem solving, and the encouragement needed for such a habit to take root. And the list goes on, in the lean community and beyond.
Similarly, at IBM, the simple framework and language of the Scientific Method encouraged Jeff’s team to “think like scientists,” which helped them develop better experiments… which of course let them to generate more meaningful results.
