Overview

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.

FAQ

What is meant by “value” in software development?Value is a capability provided to a customer at the right time and at an appropriate price, as defined by the customer. In software, value is judged from the customer’s perspective and can include user value, business value, and technical value that enables future outcomes.
How do user value, business value, and technical value differ?User value directly improves the experience or capability of people using the software. Business value supports organizational goals such as revenue, risk reduction, compliance, or cost control. Technical value improves the system’s internal qualities, like maintainability, testability, observability, performance, and architectural clarity.
Why does the chapter say value is contextual rather than absolute?Because the same activity can be valuable in one situation and wasteful in another. Its value depends on factors such as system maturity, risk profile, current goals, and how the work connects to outcomes. For example, automated tests can be highly valuable in one context and a drag in another if they become slow or flaky.
What is the difference between value-adding work and non-value-adding work?Value-adding work changes the product or service in a way the customer cares about. Non-value-adding work does not directly create customer value, even if it takes time and effort. Some non-value-adding work is still necessary, while some is pure waste.
What is necessary non-value-adding work (NNVA)?NNVA is work that does not directly change customer-facing behavior but is required to deliver value safely and sustainably. Examples include automated tests, security reviews, compliance checks, deployment pipelines, monitoring, and alerting.
What makes non-value-adding work become waste?Non-value-adding work becomes waste when it is unnecessary, repetitive, or a result of avoidable system design problems. For example, manual validation, duplicate documentation, or compensating for poor tooling can consume capacity without reducing risk or improving outcomes.
What are the eight wastes in software development?The eight wastes, often remembered as TIMWOODS, are: Transport, Inventory, Motion, Waiting, Overproduction, Overprocessing, Defects, and unused Skills. They describe common patterns of unnecessary non-value-adding work in software.
How does transport waste appear in software?Transport waste is the unnecessary movement or translation of information between locations, representations, or ownership boundaries. It shows up when data or intent is repeatedly reshaped across layers, services, tools, or teams, adding friction and risk of misunderstanding.
Why are Gemba and Kaizen important in Lean software development?Gemba means going to the place where work actually happens, such as pull requests, CI pipelines, or deployments. Kaizen means making small, continuous improvements based on what you observe there. Together, they keep improvement grounded in real work instead of assumptions or abstractions.
What is the key takeaway from auditing a pull request for waste?The goal is to train your eye to distinguish value-adding work, necessary non-value-adding work, and waste. By examining a PR honestly, you can identify recurring friction, see which delays are system-driven, and spot small changes that could remove the biggest sources of waste.

pro $24.99 per month

  • access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
  • choose one free eBook per month to keep
  • exclusive 50% discount on all purchases
  • renews monthly, pause or cancel renewal anytime

lite $19.99 per month

  • access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more


choose your plan

team

monthly
annual
$49.99
$499.99
only $41.67 per month
  • five seats for your team
  • access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
  • choose another free product every time you renew
  • choose twelve free products per year
  • exclusive 50% discount on all purchases
  • renews monthly, pause or cancel renewal anytime
  • renews annually, pause or cancel renewal anytime
  • Build High Value Software Systems ebook for free
choose your plan

team

monthly
annual
$49.99
$499.99
only $41.67 per month
  • five seats for your team
  • access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
  • choose another free product every time you renew
  • choose twelve free products per year
  • exclusive 50% discount on all purchases
  • renews monthly, pause or cancel renewal anytime
  • renews annually, pause or cancel renewal anytime
  • Build High Value Software Systems ebook for free