Lean Tool: Seeing Waste
The most popular Lean Principle is ‘Eliminate Waste’. The principle focuses on to identify and remove everything and anything that does not add value to the final product. Learning to see waste is the first step in developing breakthroughs with lean thinking.
Today we will see the first of the tools for implementing Eliminate Waste, called Seeing Waste.
“The most dangerous kind of waste is the waste we do not recognize.” ~ Shigeo Shingo
What is Waste:
Waste is anything (extra features, Requirement churn, Slow internal communication or processes, Bureaucracy etc.) that does not add value to a product, value as perceived by the customer. If there is a way to do without it, it is waste. The outcome of waste reduction is improved processes and increased value for the customer. Waste reduction is a central tenet to Lean.
Waste is a symptom of some underlying problem. Lean works to eliminate waste by
understanding the causes of these problems and addressing them at the root.
One of the most powerful aspects of Lean thinking is that it teaches team members to view their processes through a new lens. It teaches us to understand and seek out waste and it
requires us to question “why” things are done the way they are done.
The Seven Wastes of Manufacturing:
The seven wastes of manufacturing were originated in Japan, where waste is known as
“muda.” “The seven wastes” is a tool to further categorize “muda” and was originally
developed by Toyota’s Chief Engineer Taiichi Ohno as the core of the Toyota Production System & Lean Principles. The seven wastes consist of:
T – Transport – Moving people, products & information
I – Inventory – Storing parts, pieces, documentation ahead of requirements
M – Motion – Bending, turning, reaching, lifting
W – Waiting – For parts, information, instructions, equipment
O – Over production – Making more than is IMMEDIATELY required
O – Over processing – Tighter tolerances or higher grade materials than are necessary
D – Defects – Rework, scrap, incorrect documentation
S – Skills – Under utilizing capabilities, delegating tasks with inadequate training
The eight waste (last one) term was introduced by Ben Chavis, Jr. later
The Seven Wastes of Software Development
To aid software development professionals in their quest to find that elusive thing
called waste, Mary & Tom translated the seven wastes of manufacturing into the seven
wastes of Lean Software Development.
‘Task Switching’ (In manufacturing ‘Transportation’) refers time wasted and the delays when the same resource is assigning to multiple software projects. Every time software
developer switch between tasks, he /she needs a lot of time preparation, context switching, gathering thoughts etc. – fiscally and mentally. Also need to set up the environment to start working on another task. If that time is not considered in the project estimation, it will be difficult to finish both tasks/projects on stated dates. Thus, the Lean principle “Delivery as fast as possible” will have to take a hit.
Partially Done Work
‘Partially Done Work’ (In manufacturing ‘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. May be 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 delays in the development.
Minimizing partially done software development is a risk-reduction as well as a waste-
‘Motion’ (In manufacturing as well ‘Motion’ or flow) refers to availability of the knowledge, the information to execute the specific task at hand. It is known fact that knowledge / context is lost every time you hand a deliverable off to another team member (analyst, designer, programmer, tester, etc.) in flow. It’s estimated that approximately 50% of tacit knowledge – know-how possessed only by an individual and difficult to communicate to others via words, symbols or documents.
When such information gap happens, how much motion/movement does one need to do to find out the answer? Are people at hand to help with a technical problem? Is the customer or customer representative readily accessible to answer a question about features? Can the developer find out the results of tests without walking down the hall?
It is for this reason that agile software development practices generally recommend that a team work in a single workroom where everyone has access to developers, to testers, and
to customers or customer representatives.
‘Waiting / Delay’ (In manufacturing ‘Waiting’) refers to waiting for things to happen. Delays in starting a project, delays in staffing, delays due to excessive requirements, documentation, delays in reviews and approvals, delays in testing, and delays in deployment are waste.
That introduces discontinuity, triggers the appearance of all the other wastes, and keeps
the customer from realizing value as quickly as possible.
‘Extra Features’ (In manufacturing ‘Over Production’) refers to any feature added to the final product. It may seem like a good idea to put some extra features into a system just in case they are needed. Developers might like to add a new technical capability just to see how it works. This may seem harmless, but on the contrary, it is serious waste. Every bit of code in the system has to be tracked, compiled, integrated, and tested every time the code is touched, and then it has to be maintained for the life of the system. Every bit of code increases complexity and is a potential failure point.
If code is not needed now, putting it into the system is a waste. Resist the temptation.
‘Extra Processes’ (In manufacturing ‘Extra Processing’) refers to any process or activity
that doesn’t add value to the product. You should always ask a question to team or
yourself if a process or activity is really necessary?. i.e. Do you ever ask, Is all that
paperwork really necessary? Paperwork consumes resources. Paperwork slows down response time. Paperwork hides quality problems. Paperwork gets lost. Paperwork degrades and becomes obsolete. Paperwork that no one cares to read adds no value.
A good test of the value of paperwork is to see if there is someone waiting for what is
being produced. If an analyst fills out templates, makes tables, or writes use cases that
others are eager to use—for coding, testing, and writing training manuals—then these
probably add value.
Consider writing customer tests instead of requirements. If you must produce paperwork that adds little customer value, there are three rules to remember: Keep it short. Keep it high level. Do it off line.
‘Defects’ (In manufacturing ‘Defects’) refers to any error, bug, failure that produces an
unexpected result. The amount of waste caused by a defect is the product of the defect
impact and the time it goes undetected. A critical defect that is detected in three minutes is not a big source of waste. A minor defect that is not discovered for weeks is a much bigger waste. The way to reduce the impact of defects is to find them as soon as they occur. Thus, the way to reduce the waste due to defects is to test immediately, integrate often, and release to production as soon as possible.
– Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck – 2003