Seven Wastes of Software Development
value: anything of worth that the customer will pay for.
waste: anything the business does, or produces, that the customer will not pay for.
Scrum, and its practices, roles and meetings, are designed to help you visualize waste in your product development process and within your organization. In the language of Scrum, we call waste “impediments” or “obstacles”. It is very important to remove the obstacles because they are impediments to delivering value to your customer fast and impediments to self-organization and high-performing teams. As you become more comfortable with Scrum and your role as Product Owner, ScrumMaster or Team member, seeing waste will be one of the first breakthroughs of learning how to leverage Scrum to create real and lasting change.
In order to help you with seeing waste, I have used the work of Mary and Tom Poppendieck and their two books, Lean Software Development: An Agile Toolkit and Implementing Lean Software Development: From Concept to Cash, to create a list of seven common wastes of software development. Mary and Tom do a great job of mapping the Seven Wastes of Lean Manufacturing to software development and I encourage you to read their books if you want to know more about Lean Thinking applied to software.
The Seven Wastes of Software Development are listed to below to help open your eyes. As you read this list, make a note of the common wastes that you encounter each day and their impact on your work. I might even suggest that your consider showing this list to someone else in your organization and start a dialogue on what wastes are common in your business and how you might begin to remove them, or mitigate their impact.
- Partially Done Work: partially done work has a tendency to become obsolete and it gets in the way of other development that might need to be done. Examples of partially done work are uncoded requirements or designs, unsynchronized code, untested code, undocumented code and undeployed code. Partially done work ties up resources in investments that have yet to yield results and since the work is not finished, we cannot reallocate staff to the next important business initiative. The big problem with partially done work is that you have no idea whether or not it eventually will work, when it will get into the hands of your customer or that when it is finally delivered, it is valuable to the customer. Another word for partially done work is called inventory.
- Extra Processes: do you ever ask yourself, “Are all these processes really necessary?” Processes consume time and resources. Extra processes slows down response time. Processes hide quality problems and extra processes no one really cares about add no value. When we look at processes, we need to ask ourselves are they the most efficient, effective means to transmit the information or achieve the goal. Often times that are not are candidates for elimination.
- Extra Features: it may seem like a good idea, perhaps even harmless, to put in a few extra features into a system “just in case” they are needed. Technical people talk a good game on why they are essential, but on the contrary, extra features are serious form of waste. Every line of code in the system has to be tracked, compiled, integrated and tested each time the code is touched and has to be maintained for the life of the system. Each bit of code increases complexity, is a potential failure point and it is probable it may even become obsolete before it is used. Another term for extra features is called overproduction.
- Handoffs: in many software projects we transmit knowledge and information via documents – requirements move from analysts to designers, then design documents move from designers to programmers, code moves from developers to testers and so on. Each handoff is fraught with opportunities for waste. The biggest waste of all in handoffs is the information loss. We cannot possibly pass along all the information that is needed to the next person in the line. An enormous amount of tacit knowledge and learnings about the customer remain behind and never reach the receiver.
- Delays: one of the most sizable forms of waste in software development is usually waiting for things to happen. Delays in starting a project, delays in staffing, delays due to excessive requirements documentation, delays in reviews and approvals, delays in testing and delays in deployment are waste. Delays are common in software development and it would seem counterintuitive to think of them as waste. Yet, each delay keeps your customers and users from realizing the value of your system and allows a competitor to edge into your market.
- Task Switching: assigning people to multiple projects simultaneously is a source of waste. Every time a team member switches between tasks, a significant switching time is incurred as they get their thoughts gathered, reoriented to the new work and get into the flow of the new task. Add in people belonging to multiple teams and we create many more interruptions and thus more task switching. This has been know since Tom DeMarco and Timothy Lister wrote Peopleware in 1987 and was reinforced in 2001 by researchers at the University of Michigan Ann Arbor. They showed that worker productivity drops between 20% to 40% as one switches between tasks. When this happens multiple times a day, this time lost, called context switching, adds up fast. Context switching is pure waste and should be avoided.
- Defects: the amount of waste caused by a defect is the product of the impact of the defect and the time it goes undetected. A critical defect that is detected in three minutes is not a big source of waste. A minor defect that is not discovered for weeks is a much bigger waste. The way to reduce the impact of defects is to find them as soon as they occur by testing immediately, integrating often and releasing to production as soon as possible.
Remember, if something does not directly add value as perceived by the customer, it is considered waste. If you can do without it, it’s waste.
