Building a Better Mousetrap at AME

Durward Sobek, Michael Kennedy and I conducted a workshop on lean product development at last week's Association for Manufacturing Excellence conference.

The workshop uses the Mousetrap® game as a product development challenge: can you build a better mousetrap? Here is the "before" picture (Mousetrap 1.0):



The purpose of this workshop is to help people gain more comfort using rapid learning cycles as part of the product development process. The teams develop Mousetrap 2.0, 3.0 and 4.0 in iterative development cycles, use LAMDA to investigate their ideas and A3 reports to document their findings.

The groups are all part of one development team competing for a customer order against a competitor who has set a high bar for performance.





This time, all four teams could only catch 7 mice in five minutes, using three people with the original set up. The "winning" solution, which included ideas from all four teams, caught 23 mice in 5 minutes with only one person, a 10X improvement in mice caught per minute per person.

By sharing the best ideas among the entire group, we end up with at least one solution that will work among the four teams, demonstrating the value of set-based design when the team has a high degree of technical risk and a lot riding on the outcome.

The group used rapid prototyping tools (scissors, masking tape, construction paper) to quickly design and test their ideas in ten minute development cycles, followed by five minute trials.

Special thanks goes to Jamie Flinchbaugh and the Lean Learning Center who originally developed this simulation, and helped me adapt it to product development.

LAMDA is Fundamental

A client of mine helped remind me about how central LAMDA (Look-Ask-Model-Discuss-Act) is to lean product development. LAMDA is Allen Ward's expression of Plan-Do-Check-Act, which is itself an expression of the scientific method we were all taught in seventh grade science. It is the problem-solving tool that Taichi Ohno used to invent the Toyota Production System. If PCDA works for Toyota, then why do we use LAMDA for lean product development? Because Allen was teaching impatient Americans who couldn't wait to get to the Act step.

I was guilty of this myself. I would do a little bit of Planning, Do a little bit, spend a few quick minutes Checking and then run off to Act - if I bothered to do all the steps. More typically, we'd skip the Plan-Do-Check (we know what to do already and we know it's going to work), and jump straight to Act. Is it any wonder why casual implementations of lean tend to fade away?

Allen dug a little more deeply into the kinds of things that went into the Plan step to find out what was actually happening. He found Look: go to the source, get direct experience with the problem , then Ask: seek the root causes, look for reusable information. He found heavy uses of visual and physical Models to eliminate misunderstanding, improve communication and drive better decision-making by making a person's thought process visible to others. Then seemingly endless (to an American) rounds of Discussion to deepen understanding and build commitment before arriving at a decision. But the actions worked and the decisions stuck, saving enormous amounts of time and energy over implementing a solution that does not work, or revisiting a decision because it does not have everyone's commitment.

The LAMDA cycle is foundational to lean product development because product development is fundamentally about solving problems as effectively and rapidly as possible. The cycle creates the conditions necessary for deepening our personal technical knowledge and developing solutions that make the most of our organizational knowledge. It directly attacks the wastes of reinvention, unproductive meetings, organizational silos and product-centered development.0

For more information, check out my LAMDA knowledge brief.