Library→First Way: Flow→Concepts→Types of Waste
Types of Waste
The seven wastes from Lean Manufacturing applied to software. Muda, Mura, Muri — and why eliminating waste is the fastest path to flow.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
Where waste comes from
Lean Manufacturing introduced the concept of muda — the Japanese word for waste. Toyota defined waste as any activity that consumes resources but creates no value for the customer. Taiichi Ohno categorized it into seven types. Mary and Tom Poppendieck adapted these for software in Lean Software Development (2003).
In most software teams, the majority of lead time is waste. Features sit in queues waiting for review. Deployments wait for approval. Bugs are found weeks after they are introduced. Every minute of waste is a minute the customer is not receiving value.
Muda
Non-value-adding work
Activities that consume time and resources without creating customer value. The seven wastes fall here.
Mura
Unevenness
Irregular, unpredictable flow. A sprint where nothing ships for 3 weeks then 40 items ship on day 14.
Muri
Overburden
Asking people or systems to do more than they can handle. A team with 120% capacity utilization that is permanently in reactive mode.
The eight wastes of software
Lean originally identified seven wastes. A commonly used eighth (non-utilized talent) was added later. Each one appears in software delivery in recognizable forms.
Defects
Bugs, rework, failed deployments. Work that must be redone. Every bug that reaches production was cheaper to catch earlier.
Example
A security vulnerability discovered in production that could have been caught by a SAST tool in CI.
Overproduction
Building features no one uses. Implementing requirements before they are needed. The most wasteful form of waste — it creates more waste.
Example
A reporting module built speculatively that customers never requested and no one uses.
Waiting
Work sitting idle. Waiting for review, waiting for a test environment, waiting for approval, waiting for a meeting. The dominant form of waste in most teams.
Example
A PR open for 5 days while the only reviewer is on leave.
Non-utilized talent
People doing work below their capability. Developers manually running deployment checklists instead of automating them.
Example
A senior engineer spending 2 hours per deploy on a manual 40-step runbook.
Transportation
Handing work off between teams. Every handoff adds wait time and increases the chance of information loss or miscommunication.
Example
Dev writes code, hands to QA, QA finds bugs, hands back to Dev, Dev fixes, hands to Release team, Release team deploys.
Inventory
Work that is finished but not yet delivered. Completed features not yet deployed. Merged PRs not yet released. Finished work that has not yet created value.
Example
A backlog of 200 completed tickets awaiting the monthly release window.
Motion
Unnecessary movement of information. Context switching between tools. Looking up documentation in 5 different places. Overhead that adds no value.
Example
A developer who must switch between Jira, Confluence, Slack, GitHub, and a legacy wiki to start a single ticket.
Extra processing
Doing more than what is required. Unnecessary approvals, redundant documentation, gold-plating features beyond what the customer needs.
Example
A 12-step change approval process for a one-line CSS fix.
The dominant waste: waiting
In most software teams, waiting dwarfs all other wastes combined. Work sits idle far more than it is being actively worked on. A feature that takes 3 days to build might spend 30 days waiting for code review, environment access, deployment approval, or release scheduling.
This is why Value Stream Mapping focuses so heavily on wait time. Reducing wait time is almost always a bigger lever than making individual steps faster.
The Nexus Corp value stream had 7.5 days of process time and 34 days of wait time. 82% of lead time was pure waiting. Eliminating the waits — not speeding up the work — is what improves flow efficiency.
How to find waste in your team
Waste is often invisible because it has become normal. A value stream map makes it visible. When you trace a single feature from idea to production, ask at each step:
- 1.
Is anyone actively working on this right now, or is it waiting?
- 2.
Does this step directly transform the work toward what the customer wants?
- 3.
Would the customer pay for this step if they knew it existed?
- 4.
If this step failed silently, would anyone notice in less than a day?
- 5.
Could this step be automated, eliminated, or merged with another?
Further reading
Lean Software Development — Poppendieck
The original adaptation of Lean Manufacturing's seven wastes to software. Chapters 1-2.
Lean Thinking — Womack & Jones
Chapter 1: Value and Chapter 3: Flow. The source material from manufacturing.
DevOps Handbook
Chapter 4: Create the Foundations of Our Deployment Pipeline. How automation eliminates the dominant wastes.
The Phoenix Project
Parts 1-2: The three types of work and how unplanned work and technical debt create waste.