Waste / Muda

Lean businesses improve quality, cost and the speed of development of their products through ruthlessly eliminating waste (or muda in Japanese). Toyota have identified 7 (+1) distinct types of non-value-adding waste in business or manufacturing processes and product development processes that are documented in The Toyota Way by Jeffrey Liker:

(1) Overproduction :: producing items when orders or requests have not been received.

(2) Waiting :: people waiting for the next processing step, watching an automated task complete, waiting for upstream process triggers or waiting for faults to be corrected.

(3) Unnecessary Transport or Conveyance :: moving parts and materials between location and carrying work in progress long distances.

(4) Overprocessing or Incorrect Processing :: providing higher-quality parts or functions than is necessary. Performing unneeded steps to process the parts and inefficient processing because of poor tool or product design.

(5) Excess Inventory :: any excess raw material, WIP, or finished goods causing longer lead times, obsolescence, damaged goods, transportation, storage costs and delay.

(6) Unnecessary Movement :: any wasted motion employees have to perform during the course of their work.

(7) Defects :: production of defective parts or correction.

An 8th waste has also been identified and is often given consideration:

(8) Unused Employee Creativity :: losing time, ideas, skills, improvements and learning opportunities by not listening to your employees.

Mary and Tom Poppendieck have translated these manufacturing wastes into wastes seen in the software development environment in their book Lean Software Development. The terms used by Mary and Tom for the manufacturing wastes are in brackets.

• Overproduction == Extra Features
• Waiting == Delays
• Unnecessary Transportation or Conveyance (Transportation) == Handoffs
• Overprocessing (Extra Processing) == Relearning
• Excess Inventory (In-Process Inventory) == Partially Done Work
• Unnecessary Movement (Motion) == Task Switching
• Defects == Defects

I think Mary and Tom have done some very valuable work performing this translation and introducing these lean terms into the software development domain. I’ve always felt a little uncomfortable with a few of the translations which shouldn’t be surprising as the interpretation of these terms in the manufacturing domain has always been an art as well as a science. Here are some alternatives I’d like to suggest for us to consider within IT.

Overprocessing :: Mary and Tom translate overprocessing to relearning but that doesn’t quite sit right with me. I agree that overproduction translates very well to to building requirements that have not been requested by the customer and I also agree that context-switching causes relearning and is an issue that needs to be dealt with. Having said that I think overprocessing translates much better to ‘Gold Plating’. If I have a requirement to build, say to provide a screen displaying search results, I have lots of different options. I can fire the results to the screen in a long list, I can order by a key, I can pagenate the results etc. In the first instance I should build the simplest thing that works; anything else is overprocessing of the item. In this example that would probably be a simple list sent to the screen without sorting or pagination. To avoid this waste I often ask myself, my colleagues and my customers ‘what’s the simplest thing that works?’. We can always perform further processing later if customer demand arises.

I always found unnecessary processing and unnecessary movement a little mind-bending when I worked in the manufacturing environment so it doesn’t surprise me that I’m questioning them here. The distinction that I make is that transportation is about moving physical things over a large distance (parts, inventory, machines, WIP) and movement is about people, either moving over unnecessary distances or perform unnecessary motions. In manufacturing this is an important distinction as physical items often travel without human intervention using conveyors and robots. So, with that in mind let’s take a look at them…

Unnecessary Transportation :: in the software development world our inventory and work-in-progress items are things like requirements specifications, architecture designs and of course the code itself. We often transport these things large distances, whether we realise it or not, over the wire. Those of us that have tried working with source control systems located on another continent, or even in another office with a poor network connection in-between, will understand the waste that can be introduced to the process. The waste that is created by the transportation of these items is less visual than say watching a power-train travel the length of the plant but is no less important. I suggest that unnecessary transportation of materials through a manufacturing facility translates directly to the unnecessary transportation of the documents and code we use on software delivery projects over the wire. Keep things as close to the team as possible and components of the application as close together as possible.

Unnecessary Movement :: this one is easy now that transportation is out of the way; we need to minimise the amount of movement that the people on our teams need to perform. Who’s worked on a project with the BA on one side of the city, half of the developers on-site and the other half offshore, the business customer in another office entirely and the test team sat five floors below? It keeps project managers fit but I think that’s about the only positive. There are two things that are important to me here. Firstly, I need to co-locate the team as much as possible, including the customers. Secondly I need to organise the work environment so that it’s as conducive as possible. The location of the team has a massive impact on the efficiency of the process. I often add at least 30% to a project estimate if the team is not co-located. So, I suggest that unnecessary movement translates to a more direct translation of the unnecessary movement of the development team. It often surprises me how organisations that are prepared to spend tens of millions of dollars on development projects are reluctant to protect and maximise their investments by providing environments that are conducive to getting the best from software development teams. Location, location, location!

I’m really interested in your thoughts on these translations and terms, or any alternatives you’d like to put forward.