Lean Thinking for Software
The August 15, 2005 issue of Informationweek magazine (http://www.informationweek.com) has a short article about agile programming which is the latest in a long line of attempts to accelerate the software development life cycle. First came RAD (Rapid Application Development), spiral, and then XP (eXtreme Programming). All of these have been an attempt to apply the principles of Lean (manufacturing) to software. The good news is: "Software developers are converging on a lean methodology for software." The bad news is: "Why did it take them so long?"
When I first got into computer programming, we used the "waterfall" method of development. It involved several big steps: requirements, design, code, and test. It could take years to get a product ready for demonstration; it seemed more like a glacier than a waterfall. I once saw the father of the Waterfall method speak at a conference. Dr. Royce said that he had a much more iterative method in his mind, but the "waterfall" metaphor stuck and trapped software developers until someone coined the term "spiral" to restore the iterative concept.
This is the latest iteration on an iterative development methodology. It involves breaking projects into small, manageable modules and using highly iterative development.
How do we map the principles of Lean onto software? Simple. The core concepts are:
- Determine and create value.
Waterfall delivers the final system; agile delivers immediately usable functionality.
- Use "pull" instead of "push" systems to avoid overproduction.
Waterfall pushed solutions on users; Agile pulls the functionality out of the user bit by bit.
- One piece flow—Make the work "flow," one piece at a time; minimize interruptions.
Waterfall needed all of the modules to work; Agile creates one usable module at a time.
- Eliminate the seven speed bumps using the five S's: sort, straighten, shine, standardize, and sustain.
- Use the "five whys?" of root cause problem solving to eliminate defects.
The seven speed bumps that lean addresses are:
- Over production most often caused by producing large batches (i.e., programs). In the Waterfall method, you had to produce the entire system. And, since we couldn't demonstrate it to the customer, we often produced things they didn't want and missed functionality that they required.
In Agile, the entire project is divided into small modules that can be developed into fully functional, tested, and potentially usable releases in a short amount of time-often in less than a week or a day. Each Agile release can then be evaluated by the user and tuned before the next step is taken. This is the essence of one-piece flow using small batches.
- Excess inventory caused by over production. Waterfall produced a lot of code that was later determined to be of no value because we took the wrong path. Agile only lets you produce the code that is immediately valuable.
- Waiting. In Waterfall, modules and programs are created and unit tested and put on the shelf to await system testing. In Agile, they are immediately tested and integrated into a deliverable work product.
- Unnecessary movement of work products.
- Unnecessary movement of employees.
- Unnecessary or incorrect processing. Waterfall delivered a lot of unnecessary code. Agile helps prevent this.
- Defects leading to repair, rework, or scrap. Waterfall could let bugs sit in code for a long time before they were discovered through testing. "Instead of tacking testing onto the end, where the temptation to truncate the testing to meet deadlines is high, it's built into the coding cycle."
The only requirement for Agile is that you know the overall architecture: protocols, interfaces, and so on before starting on the project. Otherwise, the modules won't fit together.
Here's my point:
After many decades of wrestling with trying to apply the old "economies of scale" manufacturing techniques to software, the software world is stumbling its way to the "economies of speed" techniques of Lean.
What about your business? Can it wait decades to evolve into a more productive system through trial-and-error or do you need to apply the simple rules of Lean thinking to your business now?
Rights to reprint this article in company periodicals is freely given with the inclusion of the following tag line: "© 2008 Jay Arthur, the KnowWare® Man, (888) 468-1537, email@example.com."