Lean Software Development according to Poppendieck

To create a Lead process, waste should be eliminated.

Taking this approach to software development (from requirements to deployments) helps explain many of the project failures I have saw or heard about.


In software development, the following are considered waste:

1. Partially Done Work
This is hard to first see, but a module that 'almost' works (but then abandoned for months) has very little value. So is a module that is so-called complete, but is untested, and therefore the bug-fixing work is not done.
This is similar to 'inventory' in classic lean; there is a high cost in having partially-done software (the knowledge gets obsolete, APIs and other systems shift, etc) which is not obvious to management.
Also, if it isn't deployed now, there is a chance that it would never be deployed.

2. Extra process
Clearly, stacks of paper have no positive impact except whatever benefit they did to the shipping code.

3. Extra features
Any additional line of code, and every additional feature, adds system complexity. Fixing a bug would now cost more; adding other (important) features would take longer. Carrying 500 pounds of dead weight in your car is only going to slow you down, and so are deadweight features

4. Task Switching
Every time a developer has to perform multiple tasks, they all take longer, and focus is lost.

5. Waiting
Having to wait (for approval, feedback, etc) slows the project down and wastes time

6. Motion
Especially in document handoffs, when every time a document is passed to the next person, knowledge is lost.

7. Defects
Bugs slow the process down since they require fixing, testing, and can cause other types of slowdown (such as causing developers to lose focus on their new features). Buggy code takes longer to complete.