LEAN Development in IT: First Be Directionally Correct
The first goal of a lean design is to be directionally correct. Starting out in the right direction is the first priority. Teams should worry about the precision of hitting their target later.
This is in stark contrast to traditional software development methods in which teams are encouraged to gather all of the project requirements upfront. Often teams will spend weeks and months merely gathering system requirements. However, in lean development, the assumption is made that not all requirements can be known up front.
As the story goes, the IT developer went to the client and asked for all of their requirements. And the client said, show me what your system can do, and then I can give you my requirements.
Developers know intuitively that not all of the requirements for a system can be determined up front. While some gathering is needed, teams can often suffer from “analysis paralysis” if they spend too long at this phase.
Lean development seeks to be direction-ally correct in the beginning, and then worry about converging in on a solution later. A US Navy captain, Maurice Gauthier, put it this way, “Three successive pursuits of the 80 percent solution produce the 99.2 percent solution. However, pursuit of the 99 percent solution on the first attempt is a very poor investment of resources.”
The way to apply this to software development is to collect 80 percent of the requirements at the start, and then launch a series of rapid learning cycles. The end goal or target is set, or as Bart Huthwaite calls it, ‘the End-in-View” is determined upfront’. Then the team designs a series rapid learning cycles to learn, show feasibility, and to determine the course to take to hit the target. Taking the client, or future user, along with you on the journey is key. At the start of the learning cycle, tell the user what you expect to accomplish and what the team hopes to learn. Outline the questions that you hope to answer during the learning cycle. During the learning cycle and at the end, share your prototypes and your knowledge and ask for their reactions.
Every rapid learning cycle includes experiments and prototypes. In the IT system, this means that you are doing some type of rough prototype even in the earliest learning cycles. Showing the user the prototype might seem like a risk, but not if you tell them that ultimately it is an experiment that might even be thrown away later. At this stage the direction is set, but it has not been fine tuned. Then, listen to the user and let them help you inform the direction of the solution. In listening, additional requirements will be gathered and this will help to set the system in the correct direction. This is where you can gather the additional 20% of the requirements.
Each learning cycle should include some form of knowledge capture for the team for later reference. The metric sized A3 (11″ x 17″) sheet of paper, is the appropriate size to capture enough knowledge without over documenting. A lot of information can be recorded on one side of an A3sheet of paper. The A3 acts as a beacon marking where the team has been, and describes what has been learned.
I have seen this approach work with teams both large and small. It improves both the quality of the end solution, but it can also dramatically reduce the need for later user validation and testing because they were included in the early learning cycles. It is not agile development which assumes the requirements are set and the developer is merely writing code. This comes at the later stages of the project.
For a further description of rapid learning cycles, please refer to Innovative Lean Development. Thank you. And please send comments on how you have used learning cycles in your software development process.