The 7 Software Development Wastes - Part 1

June 28, 2009 by Jack Milunsky

Introduction

The more I learn about Lean, the more I realize how much we can learn from Lean teachings and how they apply to software development practices. Typically, we go about our day-to-day activities without thinking about the bigger picture. Lean specifically addresses the complete end-to-end process with the view of enhancing cycle time and quality.

Lean

Value stream mapping is one of the key areas for helping us learn where we fail, but in particular, what I'd like to address in the next series of posts are the 7 wastes which Lean identifies and which I believe are worth mentioning. Once you hear about these wastes I believe you will be more sensitive to realizing when you see these manifested in your organization and should therefore help you to enhance the overall productivity of your teams.

Mary and Tom Poppendiek are two of the thought leaders in applying Lean to software development and I would highly recommend that you buy their books or attend their courses. Mary in particular is inspirational and their knowledge in this space is profound.

7 Manufacturing Wastes

The 7 manufacturing wastes identified by Shigeo Shingo (from his studies of the Toyota production system) are listed below:

In-process Inventory
Over-Production
Extra Processing
Transportation
Motion
Waiting
Defects

Corresponding 7 Software Development Wastes

The 7 corresponding wastes in software development as defined by Mary and Tom Poppendiek are:

Partially done work
Extra Features
Relearning
Handoffs
Task Switching
Delays
Bugs

Today I'd like to address the 1st waste - Partially done work

Partially done work (In Process Inventory)

Partially done work is probably the biggest killer of all the wastes. Partially done work is essentially work-in-progress. Until this work is done, you don't know that there are quality issues i.e. you don't know that the customer will be happy. You don't know if there are going to be problems one you deploy your software onto your production systems. So the idea should be to complete work-in-progress as soon as possible i.e. minimize work-in-progress as much as possible. Examples of partially done work are:

* code that is completed but not checked in to your version control system - if it's not checked in, you don't know if your code changes are going to break the build

* undocumented code - If your code is undocumented, if the developer leaves and someone has to take over, there's going to take longer for the developer to get up to speed. Additionally, if bugs are found, it will be harder for the original developer to figure out what he has done.

* untested code (both unit tests and functional tests) - if your code is untested, you won't know till the code is in your customers hands that there is a bug. The further downstream you are in the process the more costly it's going to be to fix the bugs. So if you build quality in from the start (like writing unit tests) you'll find out the moment you execute the tests

* code that exists on your staging environment and not your production environment - I hear this all the time - "works on my machine" - enough said. Only once you're on production can you be sure the software is 100%. Production always surfaces issues, so the sooner you get it on production servers, the better.

* code that is commented out - makes the software less readable and maintainable

My advice to any company doing software development is to figure out how to get things that are in progress fully completed i.e. DONE in accordance with your definition of DONE, as early as possible. Don't put too many items into the development pipe that you know you can't complete in a given Sprint. Consider everything in your definition of Done to be completed in one cycle. Set your quality bar really high. This will help you ship faster, make your customers happier sooner.

Next week I will be going over a second type of waste - Extra Features.

Permalink