Eliminating waste is a key concept in lean process thinking. Waste reduction is often seen as a way of increasing productivity. Since lean is the grandfather of agile we can perhaps borrow this key concept and apply it to software engineering.
Through identification and elimination of waste in our software teams we can build our products efficiently, potentially reducing costs but also improving time to market.
The original 7 lean wastes were defined during the development of the Toyota Production System, in a factory production line setting. They were interpreted for software development by Mary & Tom Poppendieck in 2003 in “Lean Software Development”.
Partially done work
Any feature put on hold wastes time already invested and makes the codebase less maintainable.
A common example is when a customer requests a new feature and has the business commit to developing it urgently. The team must then stop what they are working on and work on the new feature. If the previous work is never restarted then that effort was wasteful.
Any step in your process that doesn’t add value, such as documentation that isn’t read, or additional rubber stamping. When we follow convention we often create documentation because that’s the way it’s always been done. Organisational policies often mandate a set of documents and the template for those documents. If the volume of paperwork is considerable, and goes un-read then the effort to produce it was wasteful.
Low value features that are not used or only used infrequently. Organisations sometimes rush to add a feature with the hope of winning a client, but then fail to do so. The new feature remains in the product un-used and increases the applications complexity. Because the feature is unused, no value was accrued from it.
Switching tasks reduces efficiency. The fastest way to complete two things is to do one at a time. Some developers enjoy working on two things at the same time. Others have two things in progress because one of them is “blocked”. When you switch task, there is a small-time cost to close what you were doing and regain your thoughts in the new task, known as a context switch. The cost of these context switches accumulates over time and reduces the time available for delivery.
Time lost while waiting to start, such as approval delays and dependencies. As soon as one individual needs to sign off on the architecture/design/UX/etc. then they become a bottle neck. The team cannot move forward until approval has been gained. If an item waiting on approval is low priority the team may be waiting for some time.
Time lost moving artefacts or data from one location to another or hunting for information on wikis.
Information can easily be lost if it is not labelled correctly or consistently. Imagine trying to find information relating to shopping baskets when files are named “SB design” and “sjoppinf basKITS”
The cost of fixing defects and the impact of re-work on the bottom line. The complex nature of software development makes defects inevitable but there are many ways to reduce their frequency such as testing and code reviews. A defect in a safety critical system will incur a cost to fix, and it could also be potentially life-affecting.
The 7 wastes are used in conjunction with the continuous improvement practice (kaizen) when the waste is first identified. Once identified root cause analysis is conducted then the Plan-Do-Check-Act cycle is followed to implement whatever improvements were identified.
For a Scrum team the 7 wastes can be used as part of a sprint retrospective meeting. First use the list to identify which of the wastes manifest themselves in your team. Discuss why that waste exists to see what the root cause is. You might use 5 whys or Ishikawa for that. Once you understand the cause you can address the waste by identifying an improvement action(s). Add the improvement to the next sprint backlog and implement. The following retrospective review if the waste has been eliminated.