The 7 Software Development Wastes - Lean series Part 3 - Extra Processing

Introduction

Waste is a killer in any organization. But if you don't know what to look for then you're probably not going to be able to find waste and minimize it or eradicate it. This series primarily deals with explicitly defining the 7 wastes in software development so that you can start thinking about how this may affect your ability to remain as productive as you can be. This can make a significant difference to your company's bottom line.

As reference, the first two wastes can be found in my previous blog posts here: In-Process Inventory/Partially done work and Over Production/Extra Features.

#3 - Extra processing

Extra processing in Manufacturing is the 3rd waste and this can be equated to Relearning or Rework in Software development. The time we spend relearning things we once knew or having to rework the same feature due to poor code quality can be significant in many organizations, ergo, it's important to be mindful of this. It's probably useful to list examples that would cause extra processing in software development

Undocumented code

If your developers don't document the code properly then later on when you're either fixing the code or making changes to the code due to new feature requirements, your developers (even the original author of code) are going to need to relearn why the code was written that way in the first place. Taking the time to document your code up front while it's fresh in your mind can therefore save the company time and money.

Poor planning

Some project managers assign work to developers in a haphazard manner. Although you do want to ensure there's knowledge overlap on your team, if you keep switching developers on the same features, each time a new developer takes over, he is going to have to relearn what the original developer already knows.

Poor quality

The earlier you find bugs and fix them the less costly it is for the organization. The most expensive scenario is when you find problems once they're already deployed to production. Partly this is due to the fact that the developer now has to reacquaint himself/herself with the code again. So if the developer spends the time upfront to write extensive unit tests, if the team takes the time to define proper acceptance test criteria then the chances of having to rework the code and worse yet relearn the code diminishes significantly

Task switching

The more things you throw at a developer at the same time the longer things take to get done. Task switching beyond 2 tasks is highly inefficient as the developer has to more often than not relearn or re-acquaint himself with the task context each time he switches back.

Poor communication and recording of knowledge

Today, with the proliferation of technology, there's no excuse for poor communication. Wiki's provide a great way for developers to record knowledge about their findings. And search makes it really easy to find information. I am not advocating heave documentation here. I am suggesting short summaries of information on key decisions you made during development so that if someone else has to take over or you have to come back to that code in the future, the relearning curve is not that great.

Stay tuned for the next blog post in this series which will cover the 4th waste - the equivalent of "Transportation" in manufacturing processes.

And as always, I encourage you to please leave questions and comments below if you have any.

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

[Sergey Pyatigorskiy]

Thumbs up! You are right in all the 7 points. But why only 7 of them? If we are talking just about developing some internal software product, maybe there are only 7 wastes, but if it is a custom software, than we should add a few. For instance, poor contact with the customer, or faults in the text of the agreement, or lack of interest to the real customer's needs, etc.

[Jack Milunsky]

Most wastes fall under these 7. So for example the poor communication with the customer falls under the waste category "Transportation" or "handoffs".

Thanks for your comments.
Jack

[Heiko Peters]

Test Driven Development (TDD) would be excellent mitigation for this waste