This quote came to me from John Maxwell.
It reminds me of why we are looking for Knowledge Gaps and writing A3’s in Lean Development. Ultimately, we are just making sure that the right questions are being asked and spotting the wrong questions. We are attempting to expose the things that we don’t know.
The exercise of writing Knowledge A3’s in Lean Development is meant to help us spot the wrong questions and in fact it goes a step further. It helps us ask the right questions, and then it points us to think about who can help us get the answers to the questions. This is what we do in the LOOK and ASK steps of LAMDA (the steps that Al Ward identified for Rapid Learning Cycles). We LOOK for questions to ask and then we think about who we should ASK. If we aren’t ASKing the “people at the ground” (a.k.a. People at the Keyboards, SMEs, Users, etc.) who will be using the program or innovation we are developing, then we are not going far enough. In Innovative Lean Development, this is described in the PLAN step of the Rapid Learning Cycle.
By starting with the problem statement, or as we sometimes have called it – the central question, we can stretch our minds to wonder if we have asked the right questions about different aspects of the program.
A corollary to Maxwell’s statement would be “An uncreative mind asks the right question at the wrong time, but a creative mind asks the right question at the right time.”
So – I am not at all surprised when we need to put an A3 on hold, or take one through the initiate phase and set it aside until later. We are simply identifying that it is too early to ask the questions yet. But, it is so important to at least identify the questions.
And here is something else to think about … the more questions and A3 writing that we do up front, the more complete the solution will be in the end.
Author – Innovative Lean Development
Development cycles in many organizations last from many months to years. The challenge with long cycles is that requirements will shift and change over time. And if the customer’s need changes and the project doesn’t adjust, it will miss the mark. The goal is to make the development cycle nimble and quick. In order to do so, the cycle time is shortened to something quite short. These short bursts are called rapid learning cycles. They are constructed to be very short. In some cases just a few weeks or even days. This is how long a development cycle on any new system should be: just long enough to answer the impotant questions or generate a new piece of knowledge – and prototype a solution. To apply a rapid learning cycle, try dividing a larger project into short bursts of learning. This creates a faster pace and measureable progress for the team.