Lean Software Development and the Seven Wastes

Lean Software Development is a mindset, not a methodology — it's the application of Lean manufacturing's principles and practices to software development. In practice, it comes down to three habits: keep whatever adds value, remove anything that's non-value-adding, and look specifically at the areas that cause problems often, then improve those first rather than spreading improvement effort evenly across everything.

History — Lean's roots are in manufacturing, not software. It was created as the Just-In-Time concept by Toyota's founders, Sakichi and Kiichiro Toyoda, though it was only popularized under the name "Lean Manufacturing" in the late 1990s. The goal was to improve Toyota's mass car-production system and the value it delivered to the customer, and the underlying model was borrowed from something as ordinary as a supermarket customer's shopping pattern: buy only what's needed, and only as much of it as is actually needed — not a warehouse of inventory sitting around just in case.

Lean Software Development specifically originated in the book Lean Software Development: An Agile Toolkit, written by Mary and Tom Poppendieck. It carries over the traditional Lean principles into a software context and includes a set of 22 thinking tools, each explicitly compared against agile practices the reader would already recognize.

Lean's seven principles are: Eliminate Waste, Build Integrity In, Deliver As Early As Possible, Amplify Learning, Decide As Late As Possible, Empower The Team, and Optimize The Whole. This chapter covers the first in depth, since it's the gateway to the rest; the remaining six are covered in the next chapter.

Eliminate Waste — waste (also called Muda or Muri) is anything that doesn't add value to the customer: an activity that could be bypassed entirely, one where the same results could be obtained without actually doing it, or anything sitting around not being used. The practice is to find out exactly what the customer wants, then deliver only that — what they want, when they want it, where they want it, and in the amount they actually want it. Anything beyond that is waste by definition, however well-intentioned it is.

The Poppendiecks identified seven distinct types of waste that show up repeatedly on software teams:

Partially Done Work — also called Work In Progress. Everything that's been partially developed but not finished counts here: several stories picked up by the team that don't get finished within the iteration sit as WIP that never became part of the increment. It carries no value until it's actually delivered to the customer, and it's often the direct cost of multi-tasking — a team member starts something new while waiting on something else to unblock the first task. Checked-in but untested code, discarded code, pending review comments nobody's incorporated yet, and manual work that could have been automated are all concrete examples.

Extra Processes — anything that adds work for the team without adding value to the team or the customer, and doesn't help deliver features in any way. Preparing documentation purely for the sake of preparing it, unnecessary or overlong meetings, and special reports built only to satisfy senior management are classic examples.

Extra Features — features the customer never actually asked for, even when the team genuinely believes they're a great idea. Any new idea like this should be presented to the customer or business before effort goes into it, because time spent on extra features is time not spent on the features that actually add value. Gold plating and "nice to have" additions chasing new technology for its own sake both fall here.

Task Switching — resources shared across different project teams, or team members taking on more work than they can actually address and starting several things at once rather than finishing one before moving to the next. It often comes from team members overcommitting to look good, and the constant context switching it forces leads directly to time wastage — the work doesn't get faster by being split across more things at once, it gets slower.

Waiting — time people or processes spend waiting for something else to happen: one thread waiting on another to complete, people waiting on approval from senior management or an answer to a query, or waiting on feedback from a customer or peer review. All of it compounds into the same outcome — delayed delivery and slower throughput — and downstream of that, performance issues, reduced productivity, and a dissatisfied customer.

Motion — unnecessary movement of people, artifacts, code, or anything else, beyond the physical or digital movement actually needed to complete an activity.

Defects — the discipline here is to find issues and fix them immediately, test immediately, integrate continuously, and move to production quickly rather than letting defects sit. Time gets wasted in identifying, reproducing, and fixing a defect the longer it's left unaddressed — a defect caught the moment it's introduced is cheap and localized; one left to linger grows in cost and blast radius the longer it survives in the codebase.

Study focus: when a question describes a team that keeps starting new work before finishing what's already in progress because members don't want to say no, that's Task Switching specifically — distinguish it from Partially Done Work, which is about unfinished items sitting as inventory rather than the act of juggling multiple things at once.