The 7 Wastes of Lean (Software Development)

Mary Poppendieck, largely responsible for applying lean manufacturing principles to the world of software development, maps the 7 wastes (muda) to software development in the following way:

1. Waste of inventory maps to partially done work (or work in process)
2. Waste of over production maps to delivering extra or unneeded features
3. Waste of extra processing maps to relearning
4. Waste of transportation maps to handoffs
5. Waste of waiting maps to delays
6. Waste of motion maps to context switching
7. Waste of defects maps to defects

Addressing these wastes is dependent on the organisational context but we commonly see the following (with examples):

1. Partially done work minimised by the introduction of work-in-process limits (see: kanban)
2. Avoid extra features by validating assumptions about value and needs in short feedback cycles (see: lean startup).
3. Relearning is the repeated learning of the same thing either by multiple people, or a single person, and can be addressed by healthy collaboration and communication practices, such as shared learning (see: brown bags or lunch-and-learn’s, demos, post-incident reviews), and approaches that break down knowledge silos (see: self documenting code, pair-programming and mob-programming).
4. Handoffs can be minimised, even eliminated, by building autonomous, cross-functional teams that have everything they need to go from concept to cash (see: devops, UX research).
5. Delays are often addressed by eliminated handoffs (above) and reducing dependencies between teams by bringing related work together (see: Spotify engineering culture, portfolio kanban).
6. Similarly to partially done work, context switching can be addressed by limiting work-in-process. Context switching due to unplanned work (for example, incidents) can be tackled by learning about (and addressing) the root causes of incidents (see: post-incident reviews). Context switching can also be a symptom of poor prioritisation and this can be addressed by prioritisation frameworks (see: cost of delay).
7. Defect reduction can be addressed by “building quality in” which refers to ways of working that focus on quality up front and not at the end as a gate (see: behaviour/test-driven development).

Lean also refers to mura and muri, the waste of unevenness and overburden respectively.

Mura is the waste of unevenness or inconsistency, of the things we are delivering, or in the rate at which we deliver. Consider user stories — we have mura when stories range in size from 1 day to 3 weeks, or when our throughput ranges from 2 stories per week to 20 stories per week. Mura maps to batch size. Short and consistently sized feedback cycles, through small user stories, can reduce mura in a software development context. Measure your takt-time or throughput at various levels (stories, epics, programs/projects) and at various stages to measure the unevenness of your process or workflow (see: cumulative flow diagrams). Inconsistency or unevenness can lead to periods of unsustainable pace. We can reduce mura by applying slicing techniques and methods at all levels (see: Neil Killick’s slicing heuristic).

Muri, the waste of overburden, may map to exceeding a team’s capacity to do work through various means, such as demand or lack of prioritisation (meaning everything is a priority). Muri can cause many problems from higher defect rates to poor engagement. You can measure the potential affects of muri by cross-referencing quantitative metrics like throughput and cumulative flow with team health (see: my talk on team metrics, spotify health check). Kanban’s pull principle is a counter to muri. Work-in-process limits are effective counters against both mura and muri.

(Acknowledgement must go to Matt Stine for this series of articles).