Waste in Production (Muda)
Toyota defines waste very simply. It is any part of the system that the customer would not want to pay for. That is, something that does not add value from his point of view. Errors, waiting, transporting semi-finished products from warehouse to warehouse are obvious examples. But for Toyota, waste is also excessive stocks of semi-finished or finished materials, something that in most companies would be treated as an asset, i.e. a company asset. That’s why the ideal solution at Toyota is to flow one product through the system, maximising the time from order to receipt of payment. Taiichi Ohno, creator of the Toyota Production System, claimed that waste is everywhere and you just have to look at the production process to find it. Wanting to make it easier to find and remove waste in factories, Taiichi distinguished seven types of waste or MUDA. Only by removing them does it give the company time to get on with something important from the customer’s point of view.
Waste in software development
Ohno’s model was well known in America as early as the 1990s, mainly through the book Lean Thinking by James Womack and Daniel Jones. However, it was not until 2001 that Mary and Tom Poppendieck translated waste from typical production to software development in their book ‘Lean Software Development’. In the meantime, three new wastes, related to mental work, have been added to Taiichi Ohno’s seven types of waste. Below you will find a list of the ten wastes with their equivalents for software development.
| Waste | production | software development |
|---|---|---|
|
Inventory |
Work in progress is the most serious type of waste. Inventory is anything that is not a finished product. |
Everything on which work has been started but not completed: requirements analysed but not implemented, code not integrated, functionality not tested, solution not implemented.
Inventory is the items that are being worked on, but also everything that is waiting in various queues, backlogs or requirements documents. |
|
Overproduction |
Products that noone ordered. |
Features customers do not need or use. |
|
Over-Processing |
Redundant steps in the manufacturing process, inefficient processing due to the use of an inefficient tool. |
Processes and activities that do not add value to the product. Excessive documentation. Rediscovery and re-learning. |
|
Transport |
Transfer of semi-finished products between workstations, or to and from warehouses. |
Handoffs. Transferring knowledge between employees. |
|
Motion |
Unnecessary movements made by workers, such as walking up to pick up tools, parts. |
Multitasking – an attempt to perform several tasks at the same time. Causes waiting and re-learning. |
|
Waiting |
Waiting for tools, parts, decisions. Storage of materials. |
Delays caused by waiting for information, decisions, resources, or components delivered by another team/department. |
|
Defects |
Production of defective parts and their storage, rejects and costs of repairs, rework, spare parts. |
Bugs disrupting the sustainable pace and leading to overloading employees (Muri). |
|
Wishful Thinking |
Creating plans based on unrealistic expectations rather than basing them on feedback and reality. |
|
|
Information Scatter |
Knowledge unavailable to those who need it. |
|
|
Underutilized Human Potential |
Employees not being involved in the process of continuous improvement (Kaizen). Failure to raise expectations towards employees. No employee development. Working to title. |
|
You may also refer to our download on Inefficiencies and wastes in software development.
Removing waste is not enough
Many companies focus only on waste removal forgetting, or being unaware of, both the remaining inefficiencies and Lean principles. This results in the organisation becoming too lean, even anorexic. It thus prevents it from responding quickly to changing demand for its products. Even worse are companies that try to remove inefficiencies locally (e.g. only in development) without looking at the impact of the change on the rest of the system (e.g. testing). Therefore, Lean, like Agile, needs to be introduced holistically, as a change in the culture of the organisation, rather than focusing on just a few tools.