Introduction

Lean manufacturing (or simply "Lean") refers to the manufacturing philosophy laid out in the Toyota Production System¹. By applying this philosophy systematically to the manufacture of cars, Toyota became the global leader with a brand (except for a recent hiccup or two) nearly synonymous with quality.

Lean integrates each step of the supply chain into a holistic value stream. Waste reduction, a core tenet of the Lean philosophy, is the act of stripping away (production) waste that occurs in the value stream while preserving or augmenting the value of the final product as perceived by the end-customer.

In this white paper, we will explore how the concept of Lean waste reduction has migrated from its origin in manufacturing to the software development industry through the use of Agile. First we will explore how different kinds of manufacturing waste have analogs in software development. Then, after we introduce guiding principles that the Lean and Agile philosophies share, we will discuss Agile practices that embody these principles in terms that demonstrate how they reduce software development waste.

The seven Lean wastes

The seven kinds of waste as first outlined by Taiicho Ohno², provide a framework to identify and remove waste from manufacturing. Although software development and manufacturing differ in important ways, once you start looking for the counterparts of manufacturing waste in software development it is surprising sometimes how easy they are to find.

1. Inventory. Inventory includes all parts and materials that have been purchased and are waiting to be used. It also includes work-in-process (WIP). WIP is everything that is being worked on that is not yet ready for shipment or sale. Inventory and WIP lead to waste because by definition they tie up resources that are not yet able to generate a return. In addition, the greater the inventory, the greater the risk of obsolescence, loss and write off.

   Inventory in software development. In knowledge work such as software development, we can think of inventory as being maintained in documentation and in non-deployed software. Software work-in-process (WIP) is all activity (and therefore expense) subsequent to business case approval but preceding deployment to production. This includes requirements documents, project plans, functional and design specifications, source code, test plans, and tests plus the time to create these artifacts. If a project is a year or more in duration, WIP continues to build up over the entire period prior to production use. WIP is also tantamount to the accumulation of write-off risk for software investments because if the project ends prematurely or never is delivered, no business value is generated and the WIP investment is lost.

2. Motion. Motion is the movement of people or equipment that takes place in excess of what is essential to contribute value. To paraphrase the words of Shigeo Shingo, a co-developer of the Toyota production System (TPS), it's only the last turn of a bolt that tightens it - the rest is just movement.³

   Motion in software development. Motion in team members is manifested through activities like travel time, walking to meetings, task-switching between projects and work interruptions. A 30 second work interruption can result in a five-minute think time reset for a developer.

3. Waiting. Waiting is the delay between steps in production. If an order comes in the mail and sits in a mailbox, that is the waste of waiting. If an item is assembled, the delay before it is packaged is the waste of waiting.

   Waiting in software development. Examples include waiting for milestone and change request approvals and sign-offs, waiting for clarifications and elaborations from sponsors and analysts, waiting for builds and testing to complete, waiting for your turn in meetings and conference calls, waiting for deployment schedules and architectural and code reviews. Any elapsed time in excess of what is needed to execute the added value step is a form of waiting. Looked at in that manner, even the most efficient operations still have a great deal of waiting in principle, leaving plenty of opportunity for future improvements.

4. Over-production. Over-production is production ahead of demand. For example, saleable units waiting in warehouses for buyers are over-production waste. As is the case with WIP, overproduction increases the risk of obsolescence.

   Over-production in software development. Since the model for software use is that one unit (i.e., one release) is shared by many users (even more so in SAAS environments) and the physical material cost of a software unit is minimal, over-production is not expressed as producing units in excess of demand. Rather, over-production in software development occurs when we build features that are either 1: never or rarely used or that are 2: deployed prematurely.

5. Over-processing. Over processing is processing done in excess of what is needed. Buffing a surface a minute longer than is needed for the next step in processing is a minute of processing waste. Over-processing not only consumes time and resources without adding value; it may damage or make the end-product less valuable and shorten the useful life of processing tools. The waste of waiting often leads to the waste of over-processing. Occupying your time with “busy work” may reduce the emotional distress of waiting by fostering the illusion that at least something “productive” is getting done, but if it’s not adding any value it’s making things worse.

   Over-processing in software development. Over or redundant processing in software includes low and no value meetings and conference calls, duplicative approvals, redundant reporting, redundant specifications, over-engineering code and gold-plating specifications, design and code reviews that don’t result in technical improvements. Overly detailed work breakdown structures and overly precise estimations are also forms of processing waste.

6. 

   Transport. Transportation waste is the movement of materials and goods that is not actually required to perform the processing. It also includes damage to materials and goods that are the result of transportation.

   Transport in software development. Since software comprises information electronically stored and accessed, the physically transport of materials or finished goods is of little concern. However, there is the analogous waste of translating and handing-off customer requirements through subsequent phases such as functional specifications, UML diagrams, source code and tests. In addition, there is also information loss (or the introduction of noise) that damages the information just as finished goods and materials are sometimes damaged through transportation.

7. Defects. The waste of defects refers to the cost of searching for defects, finding them and the cost of fixing the defects.

   Defects in software development. Testing and inspections that do not result in finding bugs are considered defect waste in software development. Other examples are features that were implemented but were never requested, inaccurate specifications, production bugs, and substandard user experience.