Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Recently the principles of lean manufacturing pioneered by Toyota have become popular topics in application development. In particular, Mary and Tom Poppendieck have written several excellent books describing how lean principles could be applied to software development.
These lean principles have been particularly popular in the agile methods community, where they’re used to justify the elimination of wasteful practices that don’t contribute to deliverable code during tightly bounded iterations.
Fundamental to implementing lean techniques is the identification and elimination of waste–any activity that absorbs resources without creating value. The Japanese have a wonderful word for waste, muda.
The problem in how most software organizations approach the elimination of muda is that they make assumptions about where waste hides rather than deducing it from measurement. By working from assumptions rather than data, they often miss some of the largest sources of muda and may attack the symptoms of waste rather than its sources.
The largest source of muda on most software projects is rework — the effort required to fix mistakes. The elimination of this source of muda offers a large and immediate opportunity for improving productivity and reducing development and maintenance costs.
Tragically, however, most software organizations don’t measure the effort and cost of rework. It lies hidden below the surface, sinking budgets and schedules that crash headlong into its ruinous bulges.
Why is rework not measured? Probably because most IT organizations do a poor job of tracking effort, and even those that do find it hard to get developers to separate rework from initial effort in a knowledge-intense occupation. Since few people record overtime, especially in the maelstrom of a death march, the full extent of rework goes unreported.
The few available studies of rework report that it accounts for between 30% and 50% of project effort in most organizations that have not undertaken successful process improvement. Rework numbers are painful, not only in the collecting, but also in the fessing up. Few executives want to admit they are flushing away an average 40% of their investment in applications.
The war on muda must begin as a war on rework. An attack on rework must be guided by data.
How many and what types of defects are we injecting? At what point in the development cycle are these defects being injected and detected? What is the full effort/cost of identifying, correcting, and retesting different types of defects, and how are these hours spread across the development or maintenance cycle? What is the cost of defects that escape into operations in terms of rework, liability, and lost business opportunity?
Armed with these data an organization can begin analyzing the profiles of defects causing the most rework, assess their typical causes and prioritize actions to eliminate them. (I’ve written about the Top Five Causes of Poor Software Quality).
These data are also helpful for evaluating the value of new methods and technologies. Will it really help to eliminate a significant source of defects and wasted effort?
Determining the underlying causes of defects and the most appropriate remedial actions is not simple. Too many executives have long held that they just needed to hire smarter people, when their real problem was giving impossible delivery dates to the smart people they already employed.
The types of defects made in wee morning hours are typically different from those made when work can be completed within normal working hours. Without data it is difficult to achieve profound insight into the causes and cures of software muda.
Lean techniques have worked in many other industries and they can work in software. However, lean techniques must be guided by the type of insightful data that many organizations do not collect today. Historical data tells us that rework is the largest source of muda in most software organizations. Attacking rework is the first beachhead in the war on muda.
Dr. Bill Curtis is the SVP & Chief Scientist at CAST Software.
