The Seven Wastes of Software Development
The Seven Wastes of Software Development
If you are not creating value in your product, consider whether your there are steps in your process that can be cut out to reduce waste.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Today I'd like to start a brand new series, the focus of which is the elimination of waste from our software development efforts. Waste elimination can be traced all the way back to the the mid-1900's, the birth of lean manufacturing, and the Toyota Production System (TPS).
Taiichi Ohno, father of the TPS, called it a management system for "the absolute elimination of waste" .
But what exactly is waste, and why is its elimination important?
Read the other parts in this series:
To understand Ohno's focus on waste elimination, you must first understand a bit of the problem faced by Toyota in the late 1940's. Manufacturing an automobile was an expensive process, and thus cars carried hefty price tags. And yet, the typical potential car buyer in Japan didn't have a great deal of money. For Toyota to succeed, they had to reduce the price of cars by reducing the cost of manufacturing.
At that time, the only recognized means of manufacturing cost reduction was mass production. This would mean producing thousands of units of the same type of car. However, Japan's economy simply wasn't large enough to create the necessary demand for thousands of cars. Toyota had to find another way.
Ohno's TPS was that other way. This is how Ohno described the essence of the TPS:
All we are doing is looking at the timeline from the moment a customer gives us an order to the point when we collect the cash. And we are reducing that timeline by removing the non-value-added wastes .
And there you have it. Look at the manufacturing process, strip out anything that does not add value to the customer, and you'll arrive at a cheaper, faster way of building a car. Then continually improve by iterating on the waste elimination process.
At the heart of lean software development is the same principle: eliminate waste. In order to eliminate waste, you must first be able to recognize it.
A wise man once said, "My goal is to make you so familiar with the truth that when a counterfeit looms on the horizon you'll know it instantly." The best way to recognize waste is to become intimately familiar with its opposite: value. I took a long look at value in my earlier article, User stories are one effective means for understanding what your customers truly value.
Once you have a handle on value, it's time to start looking for waste. To begin, map out all of the activities that must occur in your organization from the time a required software feature is identified until the time the customer begins deriving value from that feature. Next, uncover your biggest sources of waste and eliminate them. Rinse and repeat!
To help us in our search for waste, it helps to visit the work of another of TPS's forefathers, Shigeo Shingo. Shingo identified seven major types of manufacturing waste :
- Extra Processing
Mary and Tom Poppendieck later translated these seven wastes into "The Seven Wastes of Software Development" :
- Partially Done Work
- Extra Features
- Task Switching
Over the next seven weeks we'll look at examine each of these sources of wastes in detail. We'll look at some of their common manifestations, both in our coding practices and in our development methodologies. We'll also examine strategies for eliminating each of these wastes from our development efforts. Until next time!
 Ohno, Taiichi. Toyota Production System: Beyond Large Scale Production. Productivity Press, 1988.
 Shingo, Shigeo. A Study of the Toyota Production System. Productivity Press, 1981.
 Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.
Opinions expressed by DZone contributors are their own.