Waste
Concept
The collective name for every piece of work and every wait that produces no value for a customer, used to find what to remove.
Why it exists
There is a state where everyone is busy and what customers receive does not grow. Evenings get longer, calendars fill up, and at the end of the quarter the amount that actually shipped looks like last quarter's. Explaining that state through attitude leads nowhere, because nobody was idle.
Pagedeck had a version of this. Every team spent Friday afternoon writing a weekly report — six teams, two hours each, twelve hours a week. Mia checked the view history and found that four people had opened those reports in two months, three of whom had written them. The work was definitely done. The value it produced did not exist. Nobody had decided to keep writing them either; the practice had started when the company was twelve people and never been revisited.
There is a second idea on top of that: time nobody worked counts too. A change sitting still for three days waiting on code review lands in no one's working hours, and it still arrives three days late for the customer. The word waste puts what was built and what was waited on into one category, which moves the explanation for busy-but-flat from people to structure.
How it works
You use it by keeping the categories in hand and scanning the workplace against them. Seven are common in software work.
- Unfinished work — built but not delivered. A feature in its third month of review, changes stacked up unmerged. It produces nothing while it sits, and the longer it sits, the more it costs to merge.
- Unused features — built and never adopted. A screen used by two percent of customers still demands maintenance, tests and documentation, and it shows up in every estimate for work near it.
- Relearning — working out the same thing twice because nothing was written down. When nobody remembers why a decision went that way six months ago, the decision gets made again from scratch.
- Handoffs — the context lost whenever ownership changes. Each pass leaves something unexplained, and the receiving side either asks again or guesses.
- Task switching — the loss from moving between several pieces of work. It is called context switching, and holding three items at once means paying a re-entry cost every time you pick one back up.
- Waiting — time spent waiting for an earlier stage to finish. It usually accounts for the largest share of the total.
- Defects — work redone because it was wrong. The later it surfaces, the wider the redo. A wrong assumption caught in a design review costs an afternoon; the same assumption caught after release costs a fix, a deploy and an apology.
The way to measure it is to draw the path. A value stream lays out the stages a request passes through with the times attached, and recording worked time separately from waiting time per stage is what exposes where category six lives and how much of it there is. The share of the total that was worked on is flow efficiency, and teams measuring for the first time usually land under 15 percent. The other 85 percent is where the removable material sits.
Where it shows up
The most common use is deciding what to stop doing in a retrospective. Retrospectives tend to fill up with things to add; with the categories in hand, things to remove come out alongside them. Cutting the weekly report to fortnightly, or dropping it, is the kind of decision that comes from here.
It also helps judge requests to add a process. Proposing one more approval step is usually an attempt to prevent an incident, so you put the waiting it adds next to the size of the defect it prevents. A proposal that adds two days to every change in order to catch a mistake that happens twice a year does not balance. Two hundred changes a year paying two days each is not an exchange for two incidents.
There are structural ways to reduce it too. A WIP limit caps how many items can be in progress at once, and lowering it shrinks categories four and five together. One item carried to completion costs less switching than three carried in parallel, and less unfinished work accumulates.
Two cautions. Not all non-working time is waste. Learning, cleanup and rest deliver their value later. Waiting for code review is waste while the review itself is work that reduces category seven. The other is the concept turning into a surveillance tool. Once hunting waste becomes hunting for who did less, teams move toward looking busy and the waiting stays exactly where it was.
How it sounds at work
"Four people opened that report in two months. Let's drop it."
Removing something on the evidence that its output goes unused.
"Working time is three days and the total is twelve. The other nine are waiting."
What needs attention is the queues, not the speed of the work.
"You're holding five items right now. Let's get that down to two."
Reducing switching losses and unfinished work at the same time.
Once a quarter Mia lists the team's recurring work and writes down who each item is for. The weekly report was folded into one fortnightly meeting, and of two documents holding the same content in two teams, one was deleted. Friday afternoons came back. The list is worth rebuilding each quarter because recurring work accumulates quietly — every item was reasonable on the day it was added.
Theo set two fixed review slots a day to cut the queue for code review. The hours spent reviewing stayed the same while the time changes spent sitting still dropped from three days to half a day.
What people get wrong
The most common mistake is reading waste as laziness or working speed. The word brings to mind squandered hours, so the reading is natural. But measured honestly, the largest share is waiting, and during the waiting people are busy with something else. Left in place, the belief produces improvements that push people harder while the total stays put. In a flow where nine of twelve days are queues, cutting the three working days to two leaves you at eleven.
The second is deciding that meetings and documents are waste by definition. They get used as the stock examples often enough that the conclusion sticks. The test is not the format but whether the output gets used downstream. A report nobody opens is waste; a document that lets someone who was not in the room catch up six months later is work that removes category three. Meetings are the same. Strip both out without that distinction and relearning and defects climb, so more time leaves later than was saved.
Where to go next
- Lean
see the perspective this word comes out of
- Value stream
see how to find where the waiting is
Last updated 2026-09-16