When we’re in the midst of development, especially if we are hot on the trail of a new idea, we can easily lose sight of the rhythm of the entire program in the search for solutions to individual development challenges. As long as I’ve been doing this, I’ll fall into this thinking pattern myself, such as when I was building a macro to automate our new personalized Kickoff Event kits.
Even if the team is using Agile program management methods for frequent check-ins, they can still lose sight of the big picture if they are focused on their activities instead of focusing on what they need to learn.
This is why we emphasize the need to close Knowledge Gaps systematically and permanently – otherwise, product development devolves into a series of Build-Test-Fix loops because it’s the most intuitive way to work – but our intuition is wrong.
Build-Test-Fix is the Default Mode for Product Development
Build-Test-Fix is the mode that we fall into whenever we have an idea that seems easy to realize. We try something, test it, and then iterate on it, trying lots of different things until something finally works. The solutions to our problems seem just out of reach – surely we’ll be able to fix them with just one or two more tweaks. We can be more or less systematic about this, thinking the problem through analytically, or just throwing a lot of ideas into the mix to see what sticks. Rarely are we able to remember afterwards the path we took from A to Z, and we could never write down what happened. We also had no idea how long it would take to reach a viable idea. We might get lucky and hit it right the first time, or we may be there through the night, loathe to go home because we are “so close” but ultimately forced to give up in defeat if we can’t find something before we burn out.
Product development experts have known for a long time that Build-Text-Fix only looks productive. In The Lean Startup, Eric Ries attempted to improve on this with Build-Measure-Learn, and for a team working in the Software/IT world where it’s feasible to build shippable features in one cycle, this is a big improvement.
But Build-Measure-Learn isn’t a good approach for products that are not so easily changed, and not so easy to break down into “shippable” features. For products that have to obey the laws of physics, chemistry and biology, building a product may not be the best way to run an experiment that will build the knowledge you need to close Knowledge Gaps. The best experiment to evaluate a new manufacturing method may look nothing like a final product.
From Build-Test-Fix to Design-Experiment-Capture
A mechanical engineer or a chemist needs a different type of cycle to close a Knowledge Gap: Design-Experiment-Capture. It takes a good plan to run a good experiment, and then the data from that experiment doesn’t become knowledge until it’s captured. Learning is not an explicit step in this cycle – it happens throughout the Learning Cycle.
Step 1: Design the experiment
Good experiments require some experimental design to ensure that the data from the experiments will contribute to closing the Knowledge Gap. An experiment that generates inconclusive data still generates knowledge, but not the kind of knowledge that will lead to a better Key Decision. Experiments are more likely to generate useful knowledge the first time if you have taken time to think through the hypothesis you’ll test, and then design the experiment and the data analysis methods to test that hypothesis. This is also a good time to make sure that you understand the approaches others have taken to work through similar Knowledge Gaps.
Step 2: Run the experiment and analyze the data
Whether the scientist runs the actual experiment or designates the tasks to lab technicians, it’s important for someone to write down their observations as the experiment is running. While the final results will come from data analysis, these observations can provide additional context that brings the data to life for the people who have to make the final decisions. We capture these on the Knowledge Gap report under the “What Have We Learned” right next to the charts that show the results of our data analysis.
Step 3: Capture the knowledge
A Knowledge Gap is not closed until the Knowledge Gap Report has been written and accepted by the team. We intentionally designed these reports to be relatively quick to write, and to include only the most important information. An experimenter may also write a formal lab report, but that report will probably have many fewer readers, since only those who need to know the details of the experiment will bother to open it. For most people, including team members in related subteams and other stakeholders, the Knowledge Gap report will have sufficient detail to support making better Key Decisions, and for evaluating whether the knowledge is reusable to help a future team adopt a Known Solution from this product or close a related Knowledge Gap of their own.
What About LAMDA and PDCA?
If the connection to Lean was important to a team, as it is to some teams I work with today, I would stick with PDCA loops. My colleague, Kathy Iberle explains how to use these loops to drive rapid knowledge creation in our online course “Close Knowledge Gaps Rapidly, Effectively and Completely.” Kathy outlines the PDCA process as a series of rapid experiments that can be more easily taught in the context of a course.
For many years, I advocated for LAMDA as a means to close Knowledge Gaps, partly to maintain some connection with Dr. Allen Ward’s work on lean product development, which is central to the theory underneath the framework, but not visible in the implementation.
- The LOOK and ASK steps encourage the researcher to get a good understanding of the current state of the problem and the current state of the research.
- MODEL is the Design-Experiment-Capture process outlined here for developing and running the actual experiment.
- DISCUSS is what happens at the Learning Cycle and Integration Events.
- ACT is the implementation process for incorporating the decision into the design.
The problem that I’ve encountered is that LAMDA needs to be taught first and then someone needs to provide mentoring for a person to use it well. It’s not a natural fit to replace Build-Test-Fix unless the organization is already using LAMDA in other contexts. For most of the companies adopting Rapid Learning Cycles, LAMDA becomes a barrier to mastering the framework itself. It’s better to use methods the team already knows, or to use simple Design-Experiment-Capture loops.
Most modern problem-solving methods (LAMDA, 8D, Seven Step Problem Solving, PDCA and even Eric Ries’ Build-Measure-Learn) have their roots in the Scientific Method that many of us learned in grade school: they all ask the researcher to develop a hypothesis, design a test, run it, analyze, reflect and capture the results. Over time, I’ve learned that we need to keep things as simple as possible if we want to overcome the temptation to move into default “Build-Test-Fix” mode.
Close Knowledge Gaps Scientifically and Permanently on Every Project
Every product development project – even software and IT programs – could benefit from a scientific approach to identifying and closing Knowledge Gaps. If we already knew everything we needed to know to deliver a new product, then we wouldn’t need a development project in the first place. On a small project, it may only take a team fifteen minutes to uncover a handful of Knowledge Gaps that would benefit from some targeted learning to avoid getting stuck in endless Build-Test-Fix loops.
It’s easy to fall into the fallacy that a Knowledge Gap is too small for Design-Experiment-Capture. After spending a few hours not getting very far, it turned out that just a little more structure to design better experiments would lead to a better outcome.
Further Reading:
