Skip to content
Jan 4 / richard durnall

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.

 

13 Comments

Leave a comment
  1. Jason Yip / Jan 12 2008

    My gut feel is that although there may be value to use the 7 wastes of manufacturing to help our thinking but I’m wary that trying to find translations is not actually the best approach to this.

    If we look at our software development efforts, what are the key categories of non-value adding activity?

  2. richard durnall / Jan 13 2008

    I’m not so sure Jason. Although I do think some of the comparisons we draw with Lean Manufacturing can become a little tenuous. I can’t help feeling that overprocessing, transportation and motion (+ the others) are always going to be things we can look at to find non-value adding activity, particularly for folk who are new to identifying waste and value-stream mapping. I think having this framework, whatever the environment, helps us get started on identifying waste…but I do agree that we are building software and not cars so we need to keep that in mind.

    One thing that worries me at the moment is that the Lean Software Development community is value-stream mapping the delivery process and using it to make improvements. This is a good start but simply one tool that is available to us (Lean Ops transformations often start in this ‘Tool Age’). I think unless we learn the broader framework of why Lean succeeds (and the difference between Lean and Toyota) we’re missing the point.

    Thanks for getting involved; it’s good to get challenged.

  3. Mary Poppendieck / Jan 22 2008

    Check out the book “Lean Product and Process Development” by Allen Ward. He studied the Toyota product development system and lists the wastes he finds specifically in product development. Here is a summary:

    1) The biggest waste in product development is hand-offs. A hand-off occurs whenever you separate Responsibility (What to do), Knowledge (How to do it), Action (Actually doing it), and
    feedback (Learning from results).

    2) Scatter is another big waste. This includes communication barriers, poor tools, etc.

    3) Wishful Thinking is Ward’s third waste. This has to do with guessing instead of gathering data, discarding knowledge, and – believe it or not – testing to specification instead of testing to failure. (Ward believes a product should as a matter of course meet its specification. Robust designs come from understanding and avoiding causes of failure in the design.)

    This is a completely different take on waste – one specific to product development – and one which deserves our consideration.

    Mary Poppedieck

  4. richard durnall / Jan 22 2008

    Hi Mary,

    Many thanks for the comment. Ward’s book isn’t one that I’ve read so I’ll look it up. The hand-off waste feels like a symptom of heavily silo’ed organisations; I see this problem every day and it causes a lot of pain. Cross-functional teams resolve it but Western organisations seem to have big challenges thinking in this way and structuring the organisation to deal with it.

    I’ll definitely pick up the book and let you know my thoughts….

    Thanks again.

  5. Madhav Bhatt / Jan 22 2008

    Hey Rich,

    Just a thought regarding the Unnecessary transportation waste and the comparison you have drawn to sending data back to a repository over the wire and delays incurred by that. Is this more a symptom of the Waiting waste rather then unnecessary transportation. Also this points more to problem with the devices used for transportation (slow networks, bad networks etc) rather then the process of maintaining a remote repository of data. Maybe its worth thinking about changing the devices we use for transportation rather then changing the process, because maintaing all the data/artifacts of a project in one location close to the team could result in the creation of a single point of failure or have i misunderstood it completely? In the days before the internet, data used to be saved straight onto big tapes and the tapes stored in a cool dry place for retrieval later. I guess that’s one way of saying the process has remained the same over the years but the devices used by the process have changed.

  6. richard durnall / Jan 22 2008

    Hey Maddy,

    Thanks for getting involved. The suggestion that I’m making is that for maximum process efficiency we should try to keep the team and equipment located as close to each other as we possibly can. Within this you’re right, we need to defend against single points of failure in our technology and use the most efficient transport mechanisms available at the prices we can afford. The distinction between transportation, motion and waiting is always a hard one as they are interdependent in my opinion.

  7. Dave Howell / Jan 22 2008

    The big issue with transportation of information seems to me to be not pushing it around the wires so much as pushing it in and out of the processing environment, i.e. the brain. That is, communication. Human to human communication on the whole has lousy bandwidth and fidelity – it’s a major weak point of information-processing (or knowledge work) processes. Minimising unnecessary communication and improving the performance of necessary communication is a waste reduction exercise with potentially pretty good returns. That stacks up to a certain extent with what the Poppendiecks have to say about handoffs, but it also covers communications methods (i.e. verbal vs email and the co-location issue), redundant information transfer (meeting-itis and cc spam), and the generally reduced productivity of larger and more dispersed teams.

    If you feel that way inclined you could also consider moving information around the brain (e.g. from short-term to long-term memory) as a transportation issue, which would bring task switching in here rather than under movement, though as long as we’re aware it’s a waste I don’t think it matters which form of waste we say it is.

    Likewise moving it from brain to paper, i.e.excessive documentation

  8. richard durnall / Jan 22 2008

    I love the philosophy of “redundant information transfer (meeting-itis and cc spam)” as waste. I’ve been on a campaign against it for a while and I believe that you can measure the level of dysfunction within an organisation by the amount of e-mail and meetings.
    I had the opportunity to shadow a senior executive IT manager a few years ago and he took a survival of the fittest approach where e-mail and meetings were concerned. He read few e-mails and attend as few meetings as he could get away with believing that if something was urgent enough people would come and find him. He worked in an operations environment, was ex-military, and got great results. Takes discipline and extreme confidence though!

  9. Owen Berkeley-Hill / Jan 24 2008

    The dialogue about Waste is useful, but I think in might be of greater value for the IT community to ask itself:
    1. Whether the goal is to make the development of IT applications Lean or make sure the IT applications developed, help make the businesses processes they support Lean.
    2. What does the community understand by the philosophy of Jidoka?
    3. What does the community understand by the term kaizen?
    4. When will IT embrace the principles of Total Productive Maintenance and develop applications which can be maintained by non-IT people?

    Our understanding of how the business process behaves, the wastes involved must always be the focus, not necessarily how quickly we develop that app. Value Stream Mapping (VSM) is the best tool I know to do this today, be it manufacturing, or non-manufacturing (bearing in mind that non-manufacturing processes have greater degrees of freedom — to fail). I have a hunch (no more) that guided by a good VSM, some of the issues of Oper Production described above could be minimised or even avoided.

    I think IT could be a great opportunity for Error-Proofing the problems associated with brain-to-brain communication described by Dave, but it is an opportunity which has not been exploited to any great extent. This is not a reflection on a weakness in the IT Pros DNA, but a lack of a visceral understanding of Jidoka.

    At the risk of unleashing a serious pandemic of grumpiness, I do not believe IT does kaizen (perhaps with a few exceptions).

    I hope this helps.

  10. richard durnall / Jan 24 2008

    Hey Berks,

    Your point (1) on whether we are focussed on the Lean development of IT systems or using IT systems to create Lean business processes is at the forefront of my mind at the moment. I think that our focus to date has been on the first one and that is a great place to start; there is a lot of missed value in the second one and that’s where we need to go next. I plan to write a few posts on a few interesting eBusinesses that are using IT in intelligent ways to create very Lean processes.

    I also take your point regarding kaizen. I know I’m guilty of lots of hansei (reflection) through lots of retrospective activities and not enough kaizen. I’m not sure a lot of us understand the difference yet, including me.

  11. Owen Berkeley-Hill / Jan 26 2008

    Hi Rich,
    The last 18 months have taught me a lot about kaizen, but not nearly as much as I should know or will ever know. Nevertheless, I am convinced that kaizen is a frame of mind rather than a methodology (which can be dismissed as just another tool). In the best possible interpretation, I believe kaizen, real kaizen, is close to an obsessive compulsive disorder. I am convinced that Lean is not sustainable unless you have a kaizen culture: unless you have everyone (including management) working on improving things and doing it frequently, things will begin to slide. It for this reason I’m not a great fan of kaizen-blitz sessions, or getting in external consultants. PDSA, RAPID, DMAIC are all closely related to kaizen so it is not the methodology that is important but the encouragement to learn, and this if almost invariably missing.
    The ability to learn and improve is also behind Total Productive Maintenance. A good TPM program will stretch people to learn and take responsibility for the machinery and equipment they use; for the cleanliness and maintenance, jobs usually left to the cleaners and external service engineers. A good TPM program would also yield many improvement to the equipment which made them easier to use, with less NVA effort expended, and improved quality. I do not see the same movement in the IT world where “Maintenance” is still seen, negatively as fixing “bugs”, and not kaizen. Maybe it is the nature of systems development: big bach improvements are the only way.
    Does this make sense?
    I do believe this is a rich seam for further research: Is Lean incompatible with IT? Discuss! 5000 words in my pigeon hole by Monday!

Trackbacks and Pingbacks

  1. What iteration-less agile really means « epistemologic
  2. What iteration-less agile really means « The making of Zolodeck

Leave a comment