The 7 Software Development Wastes - Lean Series Part 1 - In-Process Inventory

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.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[M. Holmgren]

Partially done work is not limited to code activities. One of the biggest wastes is too much detailed requirements specifications for future work that can not be implemented in the short future. This is rework, relearning and handoffs etc waiting to happen and thus a sure method to guarantee waste.

[Jack Milunsky]

Thanks. Yes definitely agree with you. In actual fact too much investment upfront on requirements IS "partially done" work.

Jack

[Jason Barrett]

There's also incomplete code sitting on developer branches as a consequence of changing management or customer priorities. Some of this is inevitable - the marketplace does change and development organizations just have to react. It can be minimized somewhat by breaking projects down into low-granularity tasks in the hope that module-level tasks may be deliverable even if the system-level project is held up.

[Jack Milunsky]

Agreed Jason. It's really good to actually have teams think about all this waste and what it means. It can add up over time.

Jack

[Milan Dobrota]

Requirements change. What looks good on paper might not look good once it is implemented.

[Jack Milunsky]

Agreed Milan, but that's why having a good strong PO is worth a lot. Minimizing requirements churn can help teams immensely. But one can't guarantee that requirements don't change, that's why we're in the business of being agile.

Jack

[Inventory Management Software]

Your blog was superb and you really explained it well.
Thanks for sharing.