Lean software development applies lean thinking to the flow of useful software, learning and operational improvement. Its aim is to reduce avoidable waste while delivering customer value and respecting the people doing the work. It does not mean maximizing individual utilization or removing testing and documentation.
Where lean software thinking comes from
The Lean Enterprise Institute describes lean around creating needed value with fewer resources and less waste, through ongoing experimentation. Mary and Tom Poppendieck adapted lean ideas to software in their 2003 book, Lean Software Development: An Agile Toolkit. Manufacturing roots and the publication of a software framework are different milestones; there is no need to assign both the same origin date.
For a software team, inspect the whole path from a customer need to a usable, supported change. A coding step may be fast while the request spends weeks waiting for clarification, review or release. Optimizing only coding can enlarge those queues.
Keep related terms distinct
| Term | What it contributes |
|---|---|
| Lean thinking | A way to examine value, waste, learning and the whole system |
| Agile | Values and principles for adaptive software delivery and collaboration |
| MVP | A bounded product or experiment for testing an important business assumption |
| Kanban | A strategy for managing and improving the flow of work |
| Continuous integration | Frequent integration into a shared mainline, supported by automated build and test feedback |
| Continuous delivery | Keeping software releasable through a reliable delivery process |
An MVP is not another name for lean and need not be a rough or unsafe product. The Agile principles emphasize working software, collaboration, technical excellence and reflection. These ideas can support lean work without making every practice interchangeable.
Martin Fowler’s explanation of continuous delivery distinguishes it from continuous deployment: delivery means the software can be released when needed; deployment automatically puts suitable changes into production. Simply having several developers work simultaneously is not continuous integration.
Turn the principles into observable practices
The following is a practical application checklist, rather than a new canonical list of seven principles.
- Understand value: identify the user’s task and the evidence that a change helps them.
- Reduce waste: investigate unused features, repeated handoffs, waiting, defects and avoidable rework.
- Build quality into the workflow: clarify acceptance criteria, test important behavior and make failed checks visible early.
- Learn before expensive commitments: test uncertain integrations and assumptions before scaling the build.
- Manage the whole flow: review waiting and dependencies across design, development, review, release and support.
- Respect the team: let people identify obstacles, improve their work and develop skills without treating staff as disposable waste.
- Review results: keep, adapt or reverse a process change based on observed outcomes and side effects.
Documentation, approvals and reviews can protect a necessary outcome even when users never see them. Remove a step only after understanding its purpose and the consequences of removing it.
Limit work in progress using capacity
The May 2025 Kanban Guide calls for an explicit workflow and control of started-but-unfinished work. Pull new work when capacity is available. A WIP limit restricts work items; it does not mean only one person may work at each step. Pairing or several people helping unblock an item may be appropriate.
Track started and finished boundaries consistently. WIP counts unfinished items; throughput counts finished items per period; work item age tracks elapsed time for unfinished work; cycle time covers start to finish. A service-level expectation uses a time and probability informed by history, rather than a universal deadline for every item.
A full review queue is a signal to help finish reviews or investigate the cause, not to start unlimited new development. Define how urgent incidents may interrupt normal limits and make that exception visible.
A worked improvement experiment
Consider this hypothetical team and workflow. These values demonstrate a method; they are not a Hapy case study or a promised benchmark.
The team tracks 20 similarly sized changes over four weeks. For one representative change, active work takes two days, waiting for review takes four days and waiting for release takes two days: eight elapsed working days in total. Six of those days are waiting, so adding more coding capacity is not the first experiment.
The team proposes a two-week trial: cap the review queue at three items, schedule shared review capacity and stop pulling ordinary new development when that queue is full. Three is a starting hypothesis based on this team’s capacity, not a recommended limit for every team.
| Observation | Proposed change | Measure and guardrail |
|---|---|---|
| Reviews wait without an owner | Assign a reviewer when work becomes ready | Review wait time; avoid repeated interruption of one specialist |
| Large changes are hard to assess | Split work into independently reviewable outcomes | Change size and rework; preserve integration coverage |
| Release preparation repeats manually | Standardize and automate repeatable checks | Release wait and failed releases; keep rollback and required approval |
| Clarification happens after implementation | Discuss examples before starting | Reopened work; do not turn discovery into an unlimited gate |
At the review, compare the distribution of wait and cycle times for comparable work, not just the fastest item. Check escaped defects, customer task completion and team workload. If review waiting falls but production failures or overtime rise, the experiment has not established a better overall system. A small sample supports another test, not a sweeping efficiency claim.
Adopt lean without creating new overhead
Begin with one workflow and a named improvement owner. Make work and blockers visible, collect a baseline and select one bottleneck. Give the experiment a review date and explicit quality constraints. Keep a brief decision record so the next team can understand what was tried.
The effort is worthwhile when it resolves a real constraint. Excessive measurement, meetings or a rigid board can become new sources of waste. A team facing urgent incidents may need to stabilize operations before it can run a planned flow experiment.
Use the software project planning guide to connect improvements to scope and release ownership. Hapy can help examine a delivery bottleneck and define a bounded improvement plan.
Further questions
What Does the Word ‘Lean’ Indicate in Terms of Software Development?
Lean software development applies lean thinking to customer value, learning, quality and the flow of work. It seeks to reduce avoidable waste while respecting the team and improving the whole delivery system.
Is Lean Development Agile?
Lean and Agile have overlapping concerns, including customer value and feedback, but they are not synonyms. Teams can apply lean flow improvements alongside Agile delivery practices and necessary governance controls.
