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.

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:

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.