2 Value and waste in software

Most software teams are short on clarity, not effort. Everyone feels like they’re doing “the right things”: pull requests are opened, tests are running, dashboards turn green, meetings are attended, and smiles are all around. Still, releases slip. Fixes take longer than they should. Small changes feel strangely risky. No one is slacking, but the system feels heavy. The uncomfortable part is that much of the work feels useful. Extra checks to be safe. More logging to be thorough. Another test because the last failure was painful. None of it is obviously wrong, but taken together, it slows everything down and makes it harder to tell what’s improving the product and what’s just keeping everyone busy.

2.1 Seeing value before improving flow

2.2 Types of value in software

2.2.1 User value

2.2.2 Business value

2.2.3 Technical value

2.2.4 Value is contextual, not absolute

2.3 Value-adding versus non-value-adding work

2.3.1 Value-adding work (VA)

2.3.2 Non-value-adding work (NVA)

2.3.3 Necessary vs unnecessary work

2.3.4 Necessary non-value-adding work (NNVA)

2.3.5 Unnecessary non-value-adding work

2.3.6 Using VA/NVA as a thinking aid

2.4 The eight wastes in software development

2.4.1 Transport

2.4.2 Inventory

2.4.3 Motion

2.4.4 Waiting

2.4.5 Overproduction

2.4.6 Overprocessing

2.4.7 Defects

2.4.8 Skills (unused talent)

2.4.9 From seeing waste to improving the system

2.5 Gemba and Kaizen in software development

2.6 Exercise: Audit your last pull request for waste

2.7 Summary