Finding the 8 Lean Wastes in Software Development

Any talk about lean should always include the 8 wastes, so we’ll look at how these apply to software development (or any knowledge industry). Rather than creating a whole new list of wastes, we’ll find that the originals apply just as well; we just need to shift our perspective a bit.

Muda, Mura, Muri

Before we dive into the 8 wastes, it’s important to put them into perspective. When we’re talking about improving a process within lean, there are 3 primary problems.

Muda: Waste

Mura: Variability

Muri: Stress

When we talk about the 8 wastes, we’re only talking about muda. There are two other broad categories that are at least equally, if not more, important. These other problems in a lean process are often under appreciated compared to muda, and in other posts we will look at them in depth.

For today, here are the 8 wastes.


This is the easiest of the wastes to translate because we’re all familiar with it. Any time the software does not behave as intended, it’s a defect. Defects are costly to our reputation, take time to diagnose, and are preventable.


In manufacturing, this would be unneeded movement such as reaching for tools, or walking around to get parts.

In the software development, there are many sorts of motion waste. Being required to do double data entry is an unneeded activity. Holding meetings that serve no purpose may be another. There are many examples of this, but you can often identify it because you can feel the waste. You question why you’re at the meeting or doing some activity. You feel that it’s taking your time and not adding value. All of those unnecessary activities are merely motion.


This one is what it sounds like. This is also the same in every context. If you’re just sitting around waiting for something, you’re wasting time.

Over Processing

In software vernacular, this may be called “over-engineering”. This is when we’ve simply done more work than we needed to, either because we didn’t understand the need or felt that it was worth growing the scope.

There are numerous reports of just how many features are not used in a typical software solution. The number varies, but it’s typically quoted as being over half of all features. All of this work whose output is not being used is over-processing.

Over Production

Most people take issue with this as a waste. They simply cannot understand the problem of having too much new software. Unfortunately, that’s not usually how this waste manifests itself in the software industry.

Over production can occur anywhere in the software delivery lifecycle (SDLC).

Over production occurs when requests for features come in at 20 a day but only 10 per day are reviewed.

Over production occurs if analysts are creating 10 spec documents every week and engineering can only implement 3. The analysts are over producing.

Over production occurs if the software engineers are going to complete 3 features this week but the lone DBA can only complete her work for 2 of them. The engineers are over producing.

Over production occurs if the the engineers and DBA are finishing 2 features per week but QA can only handle one. The engineers & DBAs are over producing.


This is the manifestation of all that over production. All those U reviewed ideas aging in a suggestion box are inventory. That share point drive full of year old specs are inventory. The engineering team’s backlog is inventory. Those features waiting for database changes are inventory. Those features waiting for QA are inventory. Developed software waiting for six months for the next release is inventory.

Wherever someone is over producing, we get inventory. If we have inventory, someone is overproducing.


This is the waste that is most difficult to understand in the world of software. In manufacturing, it’s easy. Needing to truck parts from one plant to another, is transport. Needing to have forklifts moving parts to work stations is transport. Taking output from one station and adding it to an internal warehouse is transport. Pulling from that warehouse for a later work station is transport.

The trick to understanding this in the world of software is understanding what is being transported. In traditional manufacturing, it’s physical goods. In software, it’s knowledge.

When a customer puts their idea into the suggestion box, they’re transporting knowledge. When the analyst reaches out to the client to understand the idea, the resulting meetings, phone calls, and conversations are all efforts to transfer knowledge. The spec written by the analyst is an effort to capture that knowledge in a refined way that is more easily transported.

When engineers pull work from their backlog, they’re extracting knowledge from a database just like a manufacturer pulls parts from a warehouse.

Software engineering itself is the transformation of one type of knowledge (a human need) into a different kind of knowledge directions for a computer). They take in knowledge, apply more knowledge, and the output is refined knowledge that benefits society in some way.

Being that it is a knowledge industry, once you understand that knowledge is what we transport thou begin to see that the most costly thing we do in software is transport knowledge. And we do it a lot. Anything we can do to decrease the number of transfers, or acclerate them, will certainly have the effect of leaning out our knowledge-based supply chain. More on that later.

Unused Creativity

This waste is also rather easily understood as it applies to software. Despite the reputation some ascribe to us, software engineers are very creative people. Software engineering itself is as much art as science (yes, there can be beautiful code, and that beauty can be across several dimensions).

Giving software engineers a solution and telling them to do it, is ignoring a wealth of creative talent.

Not encouraging them to improve their own processes, wastes human creativity.

Forcing unnecessary motion, wastes human potential.

There are a myriad of other ways human creativity is wasted in software delivery. Perhaps you can think of some you have personally experienced.


Can you see these wastes in your environment?

How would you act to get rid of them?

Can agile be a tool to address these 8 lean wastes in software delivery?

Leave a Reply