April 10, 2019

The Many Masks of Muda

A look at how to optimize your agile processes by removing any wasteful processes, or as it is known in Japanese, Muda.

The Many Masks of Muda

One of the main attractions of doing agile software development is that you get to deliver work in shorter cycles which helps identify & correct any issues before they go to far into development. However, in order to do this we need the processes & team to be as lean as possible by eliminating any "muda"

What is Muda?

Muda is a Japanese word that means uselessness or wastefulness and is a key concept in the Toyota manufacturing process, which tries to ensure optimal use of resources & increased profitability. At the end of the day, it boils down to you taking a good hard look at your team, and the processes you have, to see if they are adding value or not. By doing this, you can slowly start to eliminate the waste. Just note, that just as Jim Collins describes in his book, Good to Great, changing things takes time so don't expect it to happen overnight.

From a software development point of view, reducing your muda can increase your productivity and allow you to focus on things that provide more value to your customer.

The Many Masks of Muda

At first glance, you may think that you have a pretty efficient system going for your team, but you will be surprised where muda can lurk.


Now you may be saying that you automate items such as deployments, builds etc. But do you really have everything automated? I like to follow a general rule that if you have any form of document, or video, explaining a set of steps to follow then you have failed. The reason is, that by laying out a set of steps for someone to follow you allow human error to creep in, which can then lead to time been spent in diagnosing & correcting issues.

In addition, if you are going to be doing something more than once, or you find yourself doing something again, then automate it. You may think that automating it will take more time, but from personal experience, it really isn't true as often you forget how to do things or do it wrong and have to figure out what the problem is. Even if you have to show someone else what to, you are essentially redoing it. When you step back and look at it, all that time add up at the end of the day.


Another form of inefficiency that often creeps in are from the environment that you work in. Typical examples of these are unclear requirements, poor communication between people and even continous context switching.

If you look at the above examples, you will see that each one of them causes you to lose time. If you see those happening a lot, then you need to look at what is causing the issue and correct it as soon as possible. Every environment is different so each scenario will have to be handled appropriately.

Context Switching & Bugs

Bugs are often a cause of lot more wasted time than you think. For example, lets say your write a piece of code on Monday and check it in. Then on Thursday, the tester gets to it and files a few bugs about it. Now in order to fix the bug you need to do the following:

  • Context switch from your current work to the bug fix
  • Remember and understand the work that you done a few days ago.
  • Correct the bug & retest.
  • Revert back to your previous work

What you want to achieve is to limit the elapsed time between the finishing of the task and fixing a bug which can be done through automated testing & unit tests. By doing this, the developer will be able to easily remember the code that he was working on while it is still fresh in his memory, which in my personal experience takes the longest amount of time. I am aware that those types of tests don't always pick up all bugs, but it can help in detecting a large number of them as early as possible.


You are only a single person in a team. You aren't always aware of all of the inefficiencies that the other members in your team are experiencing, and you can't fix what you don't know.

In order to correct these issues it is important that you have a proper retrospective at the end of the sprint and assign tasks to people in the team. It is no use in identifying them or just mentioning that they need to fixed. If there is no ownership, nothing will get done.

As you can see, there are many ways in which you can optimize your processes and remove any redundant waste. I would love to hear of any optimizations that you have made in your team in the comments section below.

Until next time...keep learning!