Category Archives: Prototyping

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.

Learning Cycles and Rapid Prototyping Ironman style



Tony Stark tests his prototype suit


A rapid learning cycle calls for rapid prototyping methods.  Inside of a rapid learning cycle, an innovator creates multiple design options, and then builds and tests the prototypes.  Developing prototypes helps to eliminate the risks in development.  Although, in the case of Tony Stark’s test flight, we all realize that he should have spent a little more time analyzing the risks before taking off in his Ironman suit.  

As an illustration of rapid prototyping, consider the prototype shop that Tony Stark builds in his Malibu beachfront house.  Here he can build prototypes on his Bridgeport milling machine, use sophisticated 3D computer software, and give commands to his smart robots.  



Tony uses the workshop to create rapidly evolving versions of his IronMan suits.   His workshop is basically a rapid prototyping set-up where he can create anything from the IronMan suits to a particle accelerator.   In IronMan II, Tony digitized the model city created by his father (digital wireframes of existing objects is a technology that exists today), and then creates a full 3D model, which unlocks the secrets handed down from his father to a key new element which not only will increase the power of his suit, but save his life.  

 Tony Stark has all the technology he needs to build a small-scale particle accelerator to generate the new element for his power supply, the arc reactor.  Sound impossible to build a particle accelerate in just a few days?  Well, it is the movies after all.  Tony even uses Captain America’s shield to level out one section of the accelerator tube!  Now that is a rough, quick, and effective use of prototyping (plus a little drama and foreshadowing of future movies thrown into the mix)!  

This is a great movie and very entertaining.  The movie shows what a rapid prototyping shop of the future might look like!