Many of the roots of Agile development practices can be traced to principles of Lean Manufacturing and the Toyota Production System. From their origin in the world of manufacturing, these principles have subsequently been applied to service industries such as health care and to supply-chain logistics overall. Lean principles and practices focus on eliminating waste, reducing cycle time, and increasing the flow of value delivered to the customer/end user.
There are obvious differences between the manufacturing environment, with its focus on the repetitive delivery of identical parts and products, and the software development environment, in which variation is not only the norm but is necessary for the creation of end-user value.
However, the concept of focusing on waste as a means to reduce cycle time and increase the flow of value is equally applicable to manufacturing and to software development.
As part of its focus on waste elimination, Lean production has classified waste into eight categories: defects, overproduction, waiting, transportation, inventory, motion, extra complexity, and unused creativity. (Note that the original Toyota Production System identified seven types of waste. The eighth category, the waste of unused creativity or talent, was subsequently added.)
This post will consider three of the eight categories of waste (defects, overproduction, and extra complexity) from the perspective of software development in general and software architecture in particular.
Type of Waste
|Defects||Defect waste occurs when products or services are created or delivered that do not meet customer expectations the first time. Defect waste therefore encompasses waste incurred due to rework.|
|Overproduction||Overproduction is waste resulting from the delivery of products or services in excess of customer demand. This includes products or services delivered faster or sooner than needed or in excess quantities.|
|Extra Processing / Excess Complexity||Waste due to extra processing complexity occurs when production utilizes more parts or processing steps than is necessary to fulfill customer needs.2|
Reduction or elimination of “defect waste” has long been a concern of software development practitioners. Dramatic increases in cost when defects are identified at later points in the development cycle are often cited. Waste resulting from architectural rework in particular has the potential to reduce the flow of delivered customer value down to a trickle.
Most recently, Agile proponents have focused attention on waste due to overproduction and excess complexity. Over-building of product functionality or architecture in excess of customer needs (or in excess of your ability to reliably forecast future needs) may lead to wasted effort, complex code that is hard to modify, excessive test efforts, excessive training needs, etc. The Agile acronym YAGNI (“you ain’t gonna need it”) is, in essence, a slightly more colorful expression of the need to eliminate overproduction and excess complexity waste.
When taken to the limit, the YAGNI principle can result in extreme shortsightedness as a development team scurries from one functional release to the next, incurring more and more architectural debt until the system implodes and development halts. On the other hand, by bringing attention to overproduction and excess complexity waste, Agile has brought balance to software development financial heuristics that for many years concentrated on eliminating defect and rework waste while largely ignoring other types of production waste.
Why has defect and rework waste been the main area of focus at the expense of considering other types of waste? Here are some personal speculations:
- The focus on rework waste may be a legacy from waterfall models of development, in which requirements are identified, specified, signed off, and then locked down under costly change-control mechanisms. This model of development embodies the worldview that all requirements can be exhaustively identified and documented up front and adds to the intrinsic cost of rework by further burdening it with change-control overhead.
- Perhaps rework waste gets more attention because it’s more visible. When development of a required user feature is delayed while the architecture is reworked, it usually attracts considerable management attention. On the other hand, when a feature is delivered but not used, awareness and concern are typically not as great.
- Maybe there are some kind of neuro-economic factors at play, where failure to anticipate future needs over the course of time has had more serious negative survival implications than over-anticipation of needs and events that do not ultimately transpire. (How’s that for speculation?!)
Ultimately, each software development effort faces a unique set of challenges, opportunities, and constraints. Software processes and architectural decisions need to be guided by economic frameworks that can be tailored to reflect these considerations rather that by one-size-fits-all dictates. Incorporating the Lean focus on identifying and eliminating wasteful activities, artifacts, and deliverables can help to ensure that your project is grounded in the delivery of value.
I hope this has piqued your interest in the application of Lean principles to software architecture. I plan to explore other aspects of Lean and the remaining categories of waste in subsequent posts.
- Nanette Brown, SEI
1 Reinertsen, D.G., 2009. The Principles of Product Development Flow: Second Generation Lean Product Development