Waste 1: Partially Done Work
Inventory in software—code that exists but isn't in production.
1Inventory in Knowledge Work
In manufacturing, inventory is parts and products sitting on shelves—money tied up, space consumed, value not delivered. Lean manufacturing famously minimized inventory to near-zero.
In software, inventory is less visible but equally problematic:
- Unmerged branches: Code written but not integrated
- Open pull requests: Changes waiting for review
- Unreleased features: Completed work sitting behind feature flags
- Backlog items: Ideas documented but not built
- Requirements documents: Specs written but not implemented
- Designs: Mockups created but not built
This is partially done work—effort invested but value not delivered. It's the most expensive form of waste because it represents real investment with zero return.
The Decay Problem
Physical inventory sits on a shelf. Software inventory decays. An unmerged branch becomes harder to merge each day as the main branch evolves. Requirements documents become stale as understanding changes. The longer partially done work sits, the more effort is needed to finish it.
2Why Inventory Accumulates
Teams rarely create inventory intentionally. It accumulates through:
Large batch sizes: The bigger the feature, the longer until it's done. A three-month project is three months of inventory before any value is delivered.
Push systems: Work assigned based on availability rather than capacity. When you start more than you can finish, inventory grows.
Delayed feedback: Waiting for code reviews, QA, or approvals. Every queue is inventory accumulation.
Premature work: Starting items before they're needed. Writing specs for features that might not be built. Designing for imagined future requirements.
Fear of merging: Teams who are afraid to integrate keep changes isolated. The longer they wait, the scarier integration becomes, creating a vicious cycle.
The solution isn't to work faster—it's to work smaller. Reduce batch sizes. Implement continuous integration. Pull work based on capacity, not push based on assignments.
A team has 47 open pull requests, some months old. Each represents investment not delivering value. Merge conflicts pile up. Context is lost. Eventually, PRs are abandoned entirely—100% waste.
A team commits to main multiple times daily. No branches live more than a few hours. PRs are tiny and reviewed quickly. Inventory stays near zero. Lead time drops from weeks to hours.
3Reducing Partially Done Work
Strategies for reducing inventory:
Finish before starting: Establish WIP limits. Before starting something new, finish something in progress. "Stop starting, start finishing."
Reduce batch sizes: Break large features into small, independently valuable increments. Ship each increment before starting the next.
Continuous integration: Merge to main constantly. Don't let branches live longer than a day. Make integration boring through frequency.
Fast feedback loops: If PRs wait days for review, that's inventory. Prioritize review. Make it fast. Better yet, pair program so review is built in.
Eliminate pre-work: Don't write specs for features that aren't next. Don't design systems you're not building this sprint. Just-in-time planning.
The goal is flow: work moves through the system without piling up at any stage. When you see inventory accumulating, you've found an obstacle to flow.
Measure It
Count your work in progress. How many items are started but not done? How many PRs are open? How much unreleased code exists? Track these numbers. Reducing them is usually the fastest path to faster delivery.
- Partially done work is inventory—investment without return
- Software inventory decays, unlike physical inventory
- Large batches and push systems create inventory accumulation
- Finish before starting—stop starting, start finishing
- Continuous integration keeps inventory near zero