Muda and types of waste

How much development time have you wasted due to poor processes? How many features in your product see little day to day use? How many projects have you retired as futile?

In software development, unneeded handoffs, too many features or even inefficient learning can all serve to impede productivity. And the Japanese have a term for these kinds of wasteful practices­ —the practices that hold your team and its software output back.

It’s called “Muda”. Here, we explore the concept of Muda and the types of waste you might encounter in software development. How can you cut down on wasteful practices?

What is Muda?

Muda is a Japanese term meaning ‘futility; uselessness; wastefulness.’ It’s used to refer to waste in the production process — and any behaviour or constraint that causes it.

Muda originally comes from the Toyota Production System, a management system developed and used by Toyota.  Nowadays, the concept of Muda and the types of waste that it outlines are widely used in lean development.

Before getting to the types of waste, however, it’s worth noting that there are two key types of Muda: necessary and unnecessary. Necessary Muda, or necessary waste, refers to processes that don’t add value but are necessary for end-users. For example, things that ensure the quality of a piece of software. It’s necessary to check, but the testing itself adds no value to the product.  

Unnecessary Muda is the waste that you want to cut from your production. This is the waste that adds no value and isn’t necessary.

The seven types of waste

The original iteration of Muda covers seven different types of waste. Waste is anything that costs you time or resources but doesn’t provide value to you or the end-user.

  • Transport
  • Inventory
  • Motion
  • Waiting
  • Overproduction
  • Over-processing
  • Defects

But how do these types of waste translate to software development?

Transport waste

The first form of Muda, or waste, is that caused by transporting resources and products that aren’t needed or can stay where they are. In software development, it’s unlikely that you’re needlessly moving computers around. But you could find instances where code is being passed between teams more than is necessary.

Too many handoffs between teams mean that team members spend more time catching up with the code than they should need. Plus, it can contribute to the waste of waiting if handoffs don’t happen when they should.

You can reduce transport waste by looking for ways to reduce the number of times the code is ‘transported’. This could mean integrating disparate teams or rearranging the order of tasks, where possible.

Inventory waste

The next of the types of waste or Muda is inventory waste. This means having too much inventory or too many resources.

In software development, your product, and the components of it, are code. Your code is your inventory. So, inventory waste refers to unfinished, abandoned code. Think of the features you started then scrapped. Or the code written ‘just in case’ it’s needed. Legacy code is another example of potential inventory waste in software development.

In the fast-paced world of tech, code can quickly become obsolete. This means that your team must take time to update it if you want to use it anyway. So, set aside regular moments to update what you need and delete what you don’t.

Motion waste

Motion waste is the result of people or equipment moving more than needed. In software development, task switching and multitasking both fall into motion Muda.

Task switching and multitasking can both hurt developer focus, for a start. Every time we change task, it takes on average 15 minutes to get back into a productive flow. This is time which we could use more productively.

In other words, doing one task at a time is more efficient and effective than trying to do everything at once. So, if a team member must work on multiple projects, make sure they aren’t doing so all at once. Minimise interruptions as much as possible.

Waiting waste

The next of the types of waste or Muda is that caused by teams waiting for the previous process to finish. In software development, delays cause waiting waste. Delays are anything that prevents value-creating tasks or a process from starting.

For example, failed sprints, waiting for a core team member, or gaps between each process of your development all form delays that waste time.

For development teams, it’s hard to answer the ‘how long will it take’ question. As such, it’s hard to plan to eradicate waiting waste. Instead, it’s important that you’re ready to address delays as soon as they appear, to reduce their impact.

Overproduction waste

Overproduction Muda happens when you create too much. You’re producing more than your customers need or want. In software development, overproduction waste manifests as feature creep. That is, unneeded and unwanted features that don’t answer user needs or problems.

Surplus features clutter your user interface. They bury the value of your product for your users and can create a need for extra customer support. Plus, time and resources get consumed making them and the waste continues because your team needs to maintain them.

Reducing overproduction waste means making sure you’re only developing valuable features. Practices such as YAGNI and the MoSCoW method can help.

Over-processing waste

The Muda caused by over-processing is the waste from extra activities that you could remove or improve.

One example of this found in software development is reinventing the wheel. That is, rewriting code that has been written before. When you have a solution that works well, it makes sense to reuse it. When it comes to repetitive problems, make sure your team members are solving them without reinventing the wheel.

Another example of over-processing found in software development is when developers learn separately. Programmers must keep learning. They need to learn the progress of the product, but also new skills and trends in the tech industry. Here, mentoring is a great way to ensure your team share their knowledge.

Defect waste

The last of the types of waste or Muda is the waste caused by defects. In software development, this is the effort involved finding and fixing bugs and other problems.

When it comes to code, testing for defects is a necessary waste — your users won’t appreciate software that doesn’t work properly.

Technical debt can be another form of defect waste. It can’t scale with you long term, and so needs fixing and addressing. In many cases, the way to reduce this is to not take the shortcuts in your code in the first place. Sometimes, however, that’s unavoidable. So, be sure to set aside time to fix it before it grows out of control.

Muda and software development

By following Muda and reducing the waste in your software production cycle, you stand to improve efficiency and profitability. By tightening up your processes, you make for best use of productivity and a more efficient dev floor.

It’s important to note, however, that not all waste can (or should) be eradicated. Some of it is necessary. It’s up to your product manager to decide which processes are superfluous.

So, could your software development benefit from a Muda cleanout?

Useful links

Software project estimation: handling the dreaded ‘how long will it take?’

What is technical debt and what should you do about it?

Product management: how a new field was born