The 7 Software Development Wastes

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.

Extra Features

Over - Production / Extra Features

Over production in manufacturing amounts to production of goods that are not required or consumed immediately by a customer. This is very costly in a manufacturing plant. Inventory can become stale, superceded, damaged etc.

In the software world, over-production is the same as excess features, features not really needed by customers. My understanding is that there is evidence to backup the fact that over 60% of features in software are ever used.

The reason for excess features in software development is a direct result of traditional waterfall methods. Product managers got one shot to get all the requirements out a the beginning of the 18 month project. So we forced them to think of absolutely everything. As a result more huge amounts of time and energy went into developing software that would never actually get used.

So why is it wasteful?

Well firstly, there's the direct costs of development but there's all the indirect costs like adding complexity to the codebase, introducing unnecessary bugs, contributing to sluggish performance of the application and the list goes on.

What I love about Scrum is that it's designed to focus the organization on delivering just the most important things, just-in-time. So I'd argue that Scrum really helps mitigate the risk of over-production.

Sum it up

Be mindful of this waste, keep it at the back of your mind at all times, ask yourself "is this really necessary?"

A lean codebase is an agile codebase. It gives the product owner and stakeholders options - options to change direction at a moments notice, to respond to market conditions to be more strategic.

Extra Processing

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.

Transportation

Transportation - Hand-offs

Transportation in manufacturing corresponds to hand-offs in software development. Anytime you hand a deliverable off to a different party, there is some loss in the transfer of knowledge.

There are many such examples of hand-offs in software development:

1. Developer hands off to another developer. In this scenario if the first developer never documented the code properly it's going to take significant addition effort to figure things out. Worse, the second developer may make assumptions and, as a result, introduce bugs in the system.

2. Developers hand off code to testers to test. Many organizations still don't engage QA early enough. Bear in mind that on Agile projects, QA is involved as early as the requirements phase (not that it's a phase). If the QA has no idea what the developer did or the problems he faced or the assumptions he made, then the QA is really just shooting in the dark. It's important that the developer at least includes the QA early on, documents the feature accordingly (no long dissertations), so that an effective transition is made.

3. Handing the code over to deployment teams. Many times I find separate deployment teams struggling to figure out how to get applications deployed. Configuration settings, compile instructions etc if not properly communicated can cause significant delays.

4. Handing-off to customers. If the client is not trained properly, or the software functionality is not documented properly, there will be more support calls for example.

There are many ways in which to reduce transportation wastes in software development:

1. Ensure there is open communication between all parties. Broadband communication (as defined in Agile software development practices) is imperative.

2. Ensure proper, up-to-date and effective documentation is in place where appropriate. Identify these needs up front and ensure there are tasks for this on the backlog.

3. Include all functional areas in the development process.

Be mindful of and identify all these transition points in your organization. This will help minimize costs due to hand-offs in your organization

Motion

Motion - Task Switching

Waste #5 in manufacturing is defined as Motion. And motion can be compared to "task switching" in Software Development - as defined by the thought leaders applying Lean thinking to software development.

Task switching can be a big time waster. Studies have shown that if you're working on anything beyond two seperate and distinct tasks, your efficiency goes down drastically the more tasks you take on. The reason is quite obvious; working on software development tasks takes a lot of thought processing and task switching requires that your mind switch contexts all the time. Each time that you switch contexts, there's relearning and re-acquainting that needs to take place.

Additionally, if you are working on multiple tasks simultaneously, it's going to take you longer to complete the first and each successive tasks. If you storm the first task and get that out, you are delivering value to the customer much sooner.

It's important to be mindful of this. I have found in many organizations, especially software companies where there is a real casual atmosphere, it's easy to always interrupt developers. Interruptions are prevalent with requests. All this interruption only serves to add to the Motion bucket of waste. This is where the importance of a Product Owner, ScrumMaster and Backlog come in. These roles and any artifact are there to buffer the development teams from the noise and chaos outside of the current sprint activities.

If you're a good tough ScrumMaster, you'll see to it that priorities are all driven through the backlog and the Scrum process and that your teams are left to focus on distinct activities for maximum throughput and reduced overall cycle time in development.

Next week I will cover the 5th waste in the series - Waiting.