Lean methodology is a "production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination". Lean ideas were moved into Software Development Fields by Marry and Tom Poppendieck. It's interesting how general idea behind "Lean" (originally applied to manufacturing) can be applied for other fields (software development in this case).
Waste of Over-production
Have you ever developed a module that was never used in final product? Or end users weren't using some functionality because it was too complicated? You will probably say "yes" here (like me). How can we eliminate unneeded functionality from specs? How can we validate user interface to ensure a part of a system will be useful before actual build?
We have two opposite options here: prototyping with detailed design (yeah, Waterfall!), and iterative functionality delivery (bye, bye fixed-price contracts, welcome estimated iteration deliverables). The former is better for customer ("my budget is fixed"), the latter for development shop (lower risk of invalid estimates).
Waste of Defects
The Holly Grall of software development methodologies: to limit number of defects. There are many approaches here:
- Test-in quality at the end of a whole process (worst case IMHO)
- Parallel tests with development (waste of repeated tests)
- Automated system-level tests (may be hard to maintain!)
- Automated unit-level tests (my choose)
- Random DBC-based system level tests (promising ...)
Defect means: slower delivery and it's waste of resources (time, QA time, ...).
Waste of Inventory
Means "Holding inventory (material and information) more than required". Looks like it's missing continuous integration practices. If you working on a topic too long time integration effort might me much bigger than syncing in smaller steps (minimum once a day?). The only problem with frequent syncing might me hitting regression (thus slowing work). But we can handle that by automated testing (see "Defect" above).
Waste of Over-Processing
"Processing more than required wherein a simple approach would have done" tells us we should prefer KISS (Keep It Simple Stupid) over heavy frameworks and complicated (fat) interfaces. In my opinion not the completeness of an interface designates it's quality. Better interfaces are ones that are harder to be used in incorrect way (for example: eliminate default constructor if it does not have sense).
Waste of Transportation
"Movement of items more than required resulting in wasted efforts and energy and adding to cost", in my field possible wastes are:
- duplicating bugtrackers within one project - needs syncing in both directions
- duplicating version control storage (local SVNs + central Perforce as a real example) - requires syncing methods
- submitting code always to more than one branch - is it better to cherry-pick set of commits from branch A to B then retest before submit?
Waste of Waiting
If team A is waiting for team B to produce module that will be used by team A it's a waste of waiting. The solution:
- Create draft interfaces
- Stub implementations from lower layer
Then upper level modules can be started in parallel with lover level and stubs can be eliminated during integration. Interface will emerge as a result of two processes (A requirements + B possibilities).
Waste of Motion
How many "proxies" do we have for any information flow? Is there a person that just pushes some messages between customer and programmers without added value? Maybe we can make flows shorter (they will be faster and more effective).
Waste of Un-utilized People
Looks very similar to "Waste of waiting". Our work strictly depends on people. We can improve our tools but people will be always be most important in software development activities. Avoid "push"-style, prefer "pull"-style work item assignment.