You are here: Lean Six Sigma Home » Lean Manufacturing » 7 Wastes » The Seven Wastes of Software Engineering

The Seven Wastes of Software Engineering

by Pete Abilla on May 14, 2010

Interested in a free 25+ eBook on the 7 Wastes? Please DOWNLOAD HERE.

In this series on the Seven Wastes, we’ll attempt to highlight the 7 wastes in various industries and disciplines.  Today, we’ll consider The Seven Wastes of Software Engineering.

If the customer were to peer over your shoulder, what would they have you stop doing?

In Lean Thinking, Waste is activity that adds cost but not value – from the customer’s perspective

Given that, here are the 7 Wastes of Software Engineering:

Transportation

  • Handoffs – Movement of product that does not add value.

Inventory

  • Requirements – Product Requirements Documents (PRD), Story Cards – more material information than the customer needs
  • Completed code, but not checked-in
  • Completed code, but not documented
  • Untested code
  • Code in staging environment, but not in production environment
  • Code with overwhelming amount of comments /*comments*/

Motion

  • Task-Switching – Bodily or mental motion that does not add value
  • A evil-twin of Task-Switching is Multi-Tasking

Waiting

  • Delay – Idle time when people, material, information, or equipment is not ready
  • Waiting for project approval
  • Waiting for resources
  • Waiting for change approval process
  • Waiting for product management or requirements

Overprocessing

  • Extra Steps or Effort – effort that does not add value from the customer’s perspective
  • Having to relearn what a function, class, or piece of code does
  • Having to refactor a piece of code when it already meets requirements

Overproduction

  • More Stuff – Producing more than the customer needs or wants
  • Featuritis or Feature Bloat: more features than the customer needs, wants, or asked for
  • Wrong Thing – Building something a customer doesn’t want or does not use

Defects

  • Bugs – errors, rework, mistakes, or is missing something necessary

It’s Your Turn

What other examples do you have?  Do you agree or disagree?

search terms for this article:

waste in software development, 7 wastes of software development, seven wastes of software development, software development waste, waste software development, why software engineering waste, the seven wastes of software development, 7 wastes in software, seven waste in software development, shmula waste, software engineering waste, the seven wastes of a engineering company, agile and lean 7 wastes software development, the seven waste in engineering company, 7 wastes in software development, what companies use the 7 waste rule, what are solutions for seven wastes, 7 wastes in SDLC, seven wastes in software development, engineering company case study applying the seven waste, seven wastes in engineering department, seven wastes of lean software development, seven wastes apply to the IT industry, the 7 software development wastes - motion, the companies the suffer from 7 wastes, what is meant by 7wastages, wastes of software development, waste software projects, 7 wastes in lean in software, waste in software company, wastage in software development, the seven wastes  of software development, the seven wastes of apple inc, the seven wastes for lean software development, seven waste in engineering companies, 7 wastes software development, 7 wastes of school, 7 wastes in software development images, 7 wastes in projects, 7 wastes in lean software development, 7 wastes from it prespective, 7 wastes code, 7 wastes case study, 7 waste school example, 7 waste in software, 7 waste case study, 7 wastes software solutions, 7 wastes written project for school, change control process in software engineering waste, seven lean wastes in software, seven (7) wastages of tps, sdlc seven waste grid, LEAN wastes examples in Software engineering, lean software engineering case study, lean software development waste, how to highlight the 7 wastes in six signa, glantre engineering and 7 wastes eliminations, example of seven lean wastes in software development, customer perspective in software development, company 7 waste, 7 software development wastes lean

Related Articles:


This post was written by

{ 2 comments… read them below or add one }

Julien May 14, 2010 at 5:55 am

Great post, as always.

How about :

- No automation of recurring, low-value, low-skill tasks (data extracts, etc). I guess that qualifies for “Extra effort”.
- Spending on hardware to fix design/code issues (“servers & storage are cheaper than good developers”)
- Inertia (not quite the same as “Waiting”) : “things are different here”, “we’ve always worked like this”, etc.
- Death by meetings…

I could add a lot more :)

Reply

Patrick May 17, 2010 at 2:14 pm

Most of these are very accurate.

However, some of these can’t be avoided especially for mature companies. They sort of fall into the category of “If you do things perfectly then you don’t need CM Processes, you won’t have Bugs, etc.”

Waiting for Change Management Approval for instance is something that if you do not get proper CM review and approval you risk releasing something that has no value to the customer but has negative value and wastes more time fixing up the deployment. It actually adds more risk that you will have introduced a misconfiguration, network error, bug, etc.

In terms of requirements, it is often the case the Engineering needs far more information than the customer needs. Customers typically only focus on nominal use-cases. It’s rare that they ever consider negative use-cases and how those should be dealt with. Customers also typically focus only on functional use cases (what they can see) and rarely on the non-functional use cases (i.e. performance, availability, etc.).

I agree with Julian very much on Automation, Inertia and Death by Meetings. Meetings with no specific agenda and goal are the single biggest waste of time and money I see.

At your next meeting just look around the room, add up everyone’s hourly rate and ask yourself if you’d really pay that much for the outcome of the meeting. This is especially true when nobody had the opportunity to prepare because there was no agenda and no objective. At the end, you will generally get “Okay, let’s have another meeting in the future now that everyone understands what we were supposed to do at this one.”
Ask yourself, would I really pay this much for this outcome? If the customer is at the meeting, what do they think of our prep and did we just waste their time?

Reply

Leave a Comment