2 Value and waste in software
The chapter argues that software teams often struggle not because people are lazy, but because work that looks productive can hide delay, rework, and unnecessary complexity. It introduces a Lean mindset for software: first learn to see what kind of work is happening, then distinguish between work that creates value, work that enables value, and work that merely consumes capacity. This shift matters because many routine engineering activities feel sensible in isolation, yet together they slow delivery, increase risk, and make change harder.
Value is presented as contextual and best understood from the customer’s perspective, while also acknowledging internal customers such as developers, operations, security, and future maintainers. The chapter separates value into three connected forms: user value, business value, and technical value. User value improves the experience of people using the system; business value supports organizational goals such as revenue, compliance, and reliability; technical value improves the system’s internal health so future value can be delivered more safely and quickly. These categories are not rigid labels, but lenses for making intent explicit and judging whether work is justified by outcomes.
From there, the chapter distinguishes value-adding work from non-value-adding work, and then splits non-value-adding work into necessary and unnecessary forms. Necessary non-value-adding work includes things like testing, security checks, and deployment safeguards that protect outcomes; unnecessary non-value-adding work is waste, which shows up as delay, handoffs, overproduction, overprocessing, defects, unused talent, and other friction patterns. The chapter emphasizes that waste is usually systemic rather than personal, and recommends Gemba and Kaizen: go to where work actually happens, observe it directly, and make small continuous improvements based on what you see. An end-of-chapter exercise reinforces the lesson by asking readers to audit a pull request and classify its activities by value and waste.
A week in the life of a "simple" bug fix.
Chain-of-enablement view of how value intersects among the three core value types.
Classifications of reasoning about the value of work.
TIMWOODS for software developers.
The intersection of waste and the value categories we try to balance.
The principle of going to the Gemba directly to make informed improvements.
Summary
- Value in software is defined by who it serves and the outcomes it enables, not by how hard the work was.
- Work can add value directly, enable value at a cost, or consume effort without any benefit.
- Waste hides in reasonable, well-intentioned work; it isn’t the result of laziness.
- The eight wastes are recurring patterns in which effort fails to translate into outcomes: transport, inventory, motion, waiting, overproduction, overprocessing, defects, and skills (TIMWOODS).
- Poorly designed systems consume skilled judgment rather than improve flow. Your people compensate for structural problems.
- Gemba and Kaizen ground improvement in real work and continuous learning by insisting on direct observation of the work first, followed by small, continuous improvements instead of abstract optimization.
Build High Value Software Systems ebook for free