The Seven Wastes of Software Development

Although the Toyota Production System, and the Japanese manufacturing industry, gave us Lean manufacturing decades ago, the concepts and principles of Lean are being used in far-ranging industries, including services and software. Oftentimes, when somebody mentions Lean in the same context as software, people point to Agile development as an implementation of Lean principles, and even though it's true that Agile and Lean share similarities because of each discipline's drive towards efficiency, and you can be both an Agile and Lean shop, there are key differences between the two that mostly result from the end game.

Agile is primarily concerned with adaptability, and that is readily apparent from the Agile Manifesto. Placing emphasis on individual interactions, continuous releases, collaboration with customers, and quick responses to change requests and ever-changing requirements, allows Agile software companies to quickly adapt, respond to change, and start pushing out those modifications in a hurry. Lean software development, however, is focused on eliminating waste, much like its manufacturing big brother.

In Lean manufacturer, the seven original wastes consist of transportation, inventory, motion, waiting, overproduction, over-processing, and defects. Lean software development shares much of the same problems with waste as its manufacturing counterpart, but there are a few key differences and/or adaptations that need to made.

Made famous by Mary and Tom Poppendieck in their book Lean Software Development: An Agile Toolkit, the seven wastes of software development are: partially done work, extra features (overproduction), relearning, handoffs, delays, task switching, and defects.

Partially done work is exactly what it implies: incomplete work. In Lean terms, there is no incomplete work--only work that remains in process. If a task is started but never completed, it stays as a work in process (even if you lie to yourself and move it back to the backlog). Lean principles and Kanban management techniques want to limit too much works in process, so too much incomplete work could mean a failure in project management, problems with assigning priorities, or a breakdown in work intake procedures.

Extra features are forms of overproduction, which correlate with the original Lean wastes in manufacturing. There are a lot of features in software that are not being used and/or valued by the customers. This means that, no matter how good those features are, they constitute waste. Following a minimum viable product (MVP) model in software development helps to eliminate this waste.

Relearning is another form of waste. Despite what some may think thanks to 16 week code academies that promote graduating "software ninjas," programming is hard, and if you don't think it's hard, then you aren't actually programming (but that's another story). Discovering solutions to a problem is important, but so is remembering that solution (or putting it in a code library) to avoid having to relearn the solution at a later date.

Handoffs represent an interesting problem in software development. Many companies today require full-stack developers, and you're expected to be adept at many software languages, and expect to work on several projects, but anytime a project is handed off from one person or team to another, extra work is created in the form of training and knowledge transfer, and this assumes that nothing is lost in translation. Programmers are no longer allowed to work in silos on an individual project for a long period of time, but it's still important to manage handoffs appropriately in order to minimize waste.

The sibling to handoffs is called context switching. In context switching, a programmer is forced to jump from one project to another, but the process isn't as simple as opening a different solution. It requires a change in mental state to return to the complex mapping a programmer often does in his or her head to create the environment, knowledge, and rhythm necessary to work on a project. Jeff Atwood has a great blog post on the myths of multitasking in which he examines context switching. As much as 20% of a programmers time can be lost to context switching when a second project is added to his or her slate. By the time a third project is added, nearly half of his or her time is lost to context switching.

Delays cause waste by causing extra work. Delays that prevent work are obvious sources of waste, but also remember that a delay could be a pause in between handoffs. If functionality for a particular project is complete, but the stakeholders put off reviewing the work, and then later find issues, it forces the programmer into extra work by making he or she return to the requirements, mindset, and flow of the assignment after believing that it had already been completed.

Defects in software development are similar to defects in manufacturing, so this waste highly correlates with the original waste from manufacturing. Defects cause extra work at bad times, forcing the programmer to stop what he or she is currently working on, and causing lower quality on both the bug fix and the stopped work.

The principles of Lean work well in both manufacturing and service industries, and the ideas on eliminating waste are important to keep in mind when developing software. It may require pushing back against management in order to implement Lean processes, but that's a battle worthy of participation.