Muda, or 7 Types of Waste in Software Development

If any of you have ever looked into Lean, you’ve probably come across the seven types of waste (Muda). And since Lean was originally developed for industrial manufacturing (Toyota), I initially found it difficult to figure out how these types of waste apply to software development.

Personally, an article on kanbanize.com helped me a lot a few years ago. After reading it, I collected more examples of waste and gradually categorized them. I came to the conclusion that such an overview would be useful for every Scrum Master (and not just them). If you think about the structure of the types of waste, it will be easier for you to identify instances of them in your teams.

Waiting

Waiting is one of the most common yet least visible types of waste in software development. Unlike on a production line, where machine downtime is easily measurable, waiting in software development is hidden in email threads, ticketing systems, and “blocked” statuses. The team often doesn’t even know how much time they spend waiting; they perceive it as a normal part of the process. Yet waiting is the main cause of long lead times.

If you want to shorten delivery times, start by measuring where and for how long your requests are stuck.

Examples

• waiting for the request to be processed by the subcontractor team
• waiting for prioritization results
• waiting for the test environment to become available
• waiting for access
• waiting for the release
• Take a look at the table listing the 7 types of waste; for each type, you’ll find several examples from the IT world.

Inventory

In lean manufacturing, inventory is physically visible; it sits in the warehouse and ties up capital. In software development, inventory has a similar effect, but it is invisible. Every analysis sitting in a drawer, every piece of code waiting to be deployed, every license that no one is using represents invested labor and money that does not generate any value.

Moreover, inventory ages: an analysis completed six months ago may no longer reflect reality. The solution is to limit work in progress (WIP limit), deliver in smaller batches, and regularly review what you actually need.

Examples

• Analysis left on the shelf
• Code that’s written but never deployed
• Unused tools and licenses
• Preparing extensive or redundant documentation that isn’t used

Defects

Defects are the type of waste most teams are most familiar with: production errors, bugs reported by customers, and integrations that don’t work. Less visible but just as destructive is technical debt: poorly designed architecture, missing tests, or workarounds that gradually accumulate.

The key point is that the later you discover a defect, the more expensive it is to fix. A team that invests in continuous quality, code reviews, automated tests, and pair programming will save many times more than it invested.

Examples

• Production errors
• Technical debt

What should be included in Overproduction?

In the Lean approach, overproduction is considered the worst type of waste because it causes all the others. In software development, this means creating features that no one needs or uses. Studies repeatedly show that a large portion of the features in software products are never actually used.

The causes often include a lack of customer feedback, the belief that “we know what the user wants,” and a reluctance to halt a project in which significant investment has already been made. The solution is to validate hypotheses before you start building and not be afraid to say “stop.”

Examples

• Developing more and more features without ongoing customer feedback
• Failing to cancel a project or application that does not add value

Transport

In traditional manufacturing, handoffs involve the unnecessary movement of materials between workstations. In software development, they involve the transfer of information between people, teams, and systems. Every handoff carries the risk of lost context, delays, and misunderstandings.

A typical example is passing bugs back and forth between teams without deeper analysis, or frequent switching between tasks and projects, which destroys focus and productivity. The fewer hand-offs, the smoother and faster the delivery. Cross-functional teams with end-to-end responsibility are one of the most effective ways to minimize handoffs.

Examples

• Passing the buck between systems when looking for solutions, sometimes without further analysis (it’s not my problem now,…)
• Frequently switching attention between many parallel projects and tasks, resulting in a lack of focus
• Passing requirements back and forth between many subcontractors (both internal and external)

Overprocessing

Over-engineering occurs when we do more work than is necessary to achieve a result. In software development, this often manifests as overly complex processes or rigid workflows in tools like JIRA that people end up circumventing. An excessive focus on reporting and metrics at the expense of actual work is also considered a waste.

Paradoxically, over-engineering often masquerades as “quality” or “best practice.” The key is to regularly ask: does this step add real value? If not, simplify it or remove it. A good test is to ask the team which steps in the process they wouldn’t miss.

Examples

• Overly strict development guidelines (processes, methodology)
• A very complex workflow in JIRA that everyone skips until the request is complete and they want to close it
• Too much focus on metrics and reporting

Motion

In software development, “movement” as a form of waste manifests itself in unnecessary steps, meetings, and back-and-forth communication that add no value. This includes approval processes where a finished product is sent back and forth multiple times, as well as meetings without an agenda or clear outcomes. Constant interruptions from work also fall into this category. All of these are forms of movement that slow down delivery.

Unlike handoffs (transfers between people), motion refers more to unnecessary activity within a single team or among a single person. The solution is to shorten feedback loops, involve the right people from the start, and protect time for focused work.

Examples

• Approval loops where feedback is only provided after the work is already done, and the work goes back and forth several times
• Meetings that don’t add value
• Distractions from work

You may also be interested in

• Value Stream Mapping – a step-by-step guide to improving team efficiency
• Setting up a Kanban board: a practical guide to an effective workflow
• Want to learn more about the types of waste? Sign up for our Kanban – Flow Mastery training.