Waste elimination is one of the Lean principles and one of the most effective ways to increase quality and reduce cost. While products and services differ between industries, waste or muda – everything that does not add value from the perspective of the customer, or any material/resource beyond what the customer requires and is willing to pay for – can be found in any type of business, such as in the software development.
Mary and Tom Poppendieck – two of the leaders in describing how to implement Lean to software development – have translated the well-known “Seven Wastes of Manufacturing” into “The seven Wastes of Software Development”.
1. Partially done work (in Mfg.: Inventory): refers to any partially done software (Work In Process) that is not checked-in, integrated, tested, or deployed. Until that partially done software is integrated with the rest of the software development and then released into production, you don’t really know if it will eventually work or solve the business problem defined weeks/months ago; maybe at the time of release it is already obsolete resulting in a huge financial problem. In addition, partially done software gets in the way of other developments, so any work that is not finished triggers, for example, huge delays in the development (Waste #6).
2. Extra features (in Mfg.: Over-Production): refers to any feature added to the final product that the customer doesn’t need, want or even ask for. Any extra feature increases an unnecessary complexity, adds a potential failure point, and maybe it will become obsolete before is used. Not forgetting that as any feature, it has to be tracked, compiled, integrated, tested, and lifetime maintained.
3. Relearning (in Mfg.: Extra Processing): the first approach for this waste was Extra-process that focused on extra activities done that do not add value like excessive documentation or customer’s signoffs. After more understanding of this waste, it has been modified with the name of Relearning,referring to repeating a value adding activity spending time relearning things we have already learned. e.g.: undocumented code force to a new developer to “relearn” what was already learn for the previews programmer; a solution of an undocumented problem solved have to be relearn when the problem reappear.
4. Handoffs (in Mfg.: Transportation): refers to knowledge lost every time you hand a deliverable off to any team member (analyst, designer, programmer, tester, etc.). It’s estimated that approximately 50% of tacit knowledge – know-how possessed only by an individual and difficult to communicate to others via words and symbols – remains with the creator of the document and never get handed off to the receiver.
5. Task switching (in Mfg.: Motion): refers to time wasted when the same resource is assigning to multiple software projects. A person who have to switch from project A to project B needs a lot of time preparing himself – fiscally and mentally – and setting the environment to start working on project B. If that time is not considered in the project estimation, it will be difficult to finish both projects on stated dates. Thus, the Lean principle “Delivery as fast as possible” will not be accomplished.
6. Delay (in Mfg.: Waiting): refers to waiting for things to happen. That introduces discontinuity, triggers the appearance of all the other wastes, and keeps the customer from realizing value as quickly as possible. E.g.: delay in get the team conformed, waiting for approvals, delays due to excessive requirements documentation.
7. Defects (in Mfg.: Defects): refers to any error, bug, failure that produces an unexpected result. The formula the Poppendiecks use to quantify the amount of waste caused by a defect is: WASTE = Defect Impact * Time defect goes undetected. They said that a critical defect that is detected in 3 minutes is not a big source of waste as a minor defect discovered weeks later.
CONCLUSION
Out there are tons of tools we can use to eliminate wastes, but first of all we have to learn to see waste, a non-easy activity. Of course, there is no “silver bullet” to solve waste problems, but regardless of the methodology you use in your software company – CMMI, Agile, PMI, or a hybrid of all of them – Lean principle ‘Eliminating waste’ has huge value to get better quality, reduced cost, and faster delivery.
The more you learn about Lean, the more you will realize how much value has it when applying to software development projects. Let’s do a quick test: pick one of the wastes and see if you can identify activities in your job that do not add value and can fit perfectly under that waste umbrella.
What it would be the best way for you to get rid of those activities? Share your thoughts!
REFERENCES
– Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck – 2003
– Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck – 2003
– Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck – 2006
NOTE
Originally, I wrote this article for Christian Paulsen ’s Lean Leadership blog.
Image provided by: digitalart – FreeDigitalPhotos.net
2 Comments
Jimena Calfa · September 23, 2012 at 5:53 pm
Aderogba Adewusi from ASQ Community
I really appreciate your posts. I also believe that organizations should not just think of improving processes without involving the customer who will become the beneficiary of the change. Customers must be able to passively or actively show what their needs are. Therefore, the right thing for an organization to do is to devise means by which customers will reveal what their true needs are.
Jimena Calfa · April 4, 2013 at 11:45 pm
Comment from ASQ Software Division LinkedIn group:
Emmett Dignan: While Lean certainly has merit, I frequently find single line statement principles get applied to far more complex relationships than they were designed for.
Some commercial relationships have no direct or even quantifiable return. But an inability to accurately model or measure something does not make it cease to exist.
Comments are closed.