The seven wastes of software development

Lean Thinking is more than just a set of management tools; it is a philosophy centered on maximizing customer value while relentlessly eliminating waste. At its core, it challenges us to look at every activity through the customer’s eyes: if an action doesn’t directly contribute to the final product or service the customer wants, it is “Muda” (waste) .

While these concepts originated on the factory floors of Toyota—formalized as the seven wastes of lean (such as excess inventory and unnecessary motion)—the transition to knowledge work required a translation. In software development, waste isn’t a pile of unused steel; it is invisible, residing in code repositories, meeting rooms, and cognitive overhead.

By adapting the original manufacturing wastes, Mary and Tom Poppendieck identified the Seven Wastes of Software Development. Understanding these is the first step toward creating a “Flow” where value reaches the user as quickly as possible.

1. Partially Done Work

In manufacturing, this is excess inventory. In software, it’s code that isn’t in production. Unmerged branches, untested features, and undocumentation work are liabilities. They tie up resources and risk becoming obsolete before they ever provide value.

Countermeasure: Focus on small, incremental updates and continuous integration to keep work “done.”

2. Extra Features

Often called “over-processing,” this is the tendency to build functionality the customer didn’t ask for or won’t use. Every line of extra code increases the maintenance burden and complexity of the system without adding value.

Countermeasure: Adhere to the YAGNI (You Ain’t Gonna Need It) principle and only implement what is immediately necessary.

3. Relearning

This represents a waste of human potential. When teams fail to capture knowledge or repeat the same mistakes, they spend time “rediscovering” solutions. This is especially prevalent in fast-moving fields like AI, where the reasons behind abandoned experiments are often lost.

Countermeasure: Maintain lightweight, accessible documentation and utilize techniques like pair programming to spread knowledge.

4. Handoffs

Every time a project moves from one person or department to another (e.g., from design to development to QA), context and tacit knowledge are lost. These “silos” create significant friction.

Countermeasure: Use cross-functional teams where all necessary skills are present from start to finish.

5. Task Switching

Software development requires deep focus. When developers are forced to juggle multiple projects or are interrupted by frequent meetings, they pay a “cognitive tax.” It takes time to get back into “the zone,” leading to decreased quality and morale.

Countermeasure: Limit Work-in-Progress (WIP) and batch administrative tasks to protect “deep work” time.

6. Delays

Waiting for an approval, a server to be provisioned, or a bug report to be clarified is pure waste. Delays extend the time-to-market and stall the feedback loop necessary for improvement.

Countermeasure: Empower small, autonomous teams with the authority to make decisions quickly.

7. Defects

Rework is the most obvious form of waste. A bug caught in production is significantly more expensive to fix than one caught during initial development. Defects disrupt flow and damage customer trust.

Countermeasure: “Shift left” by writing automated tests before coding and making quality a shared responsibility rather than a final check.

Why It Matters

By identifying these wastes, teams can move toward the fifth principle of lean thinking: Perfection. This isn’t just about cost-cutting; it’s about creating an environment where developers can focus on what they do best—solving problems and building value—without being weighed down by the “Muda” of inefficient processes.

In the era of AI and rapid technological shifts, the ability to eliminate these wastes is the difference between a team that thrives and one that is buried under its own complexity.

Menu