What is “waste” (muda) in Lean?
Lean focusses on the flow of value to the customer. Everything which the product produces which aligns with the customer need is considered “Value”. The customer will pay for this because the product is addressing the customer need. In general in software development this aligns with product features.
There will inevitably be aspects of the product which do not directly address customer need. There will certainly be much of the development process which is not customer value. Anything which does not add value to the customer is viewed in Lean as “Waste” (“Muda” in Japanese). The customer will not pay for this as it does not deliver value to them. Therefore there is no benefit from the waste items.
Of course this does not mean we can simply abandon everything which is not usable by the customer. Some process is necessary. What we should do, however, is challenge and minimise cost. Lean will challenge anything which is “Waste”, even though conventionally we might see it as necessary.
When you buy bananas all you want is the fruit not the skin, but you have to pay for the skin also.
Shigeo Shingo
It is a waste.
What counts as Waste?
Lean visualises a flow of value to the customer. We can picture waste as whatever disrupts that smooth flow. In general that will be activities which consume resources or increase the cost of products or services. If it does not contribute value to the customer it is considered waste.
It is easy to interpret waste as pointless activities. However, that is not really the key message when understanding Lean. Waste activities cannot simply be stopped. In many cases they are inherent in the approach being used. In order to reduce waste, the overall approach may need to be reconsidered.
For example, imagine we have a hosted software product for which we are paying significant costs to run compute hardware. Those hardware costs are waste. The customer values our software, not our infrastructure.
However we cannot simply disconnect the hardware – it is inherent in how we do business. We could, however, consider moving to a cloud-based platform. This would potentially reduce this area of waste.
Waste in software development.
Lean was focussed originally on manufacturing. Many of the original Lean concepts of waste do not exist in software development.
- There is no “transport” when data is moved instantly between devices.
- There is no “excessive inventory” when there are no physical objects being manufactured.
- There is no “unnecessary movement” when people are not moving physical objects about a factory.
Does this mean that the “waste” concept is still valid? There clearly is still “waste” but it needs some translation to software development.
Types of software waste
Mary Poppendieck in her book “Lean Software Development” did significant work to retarget Lean away from manufacturing and towards the software world. Poppendieck looked at the key areas of waste in software development. These were based on the key wastes in Lean manufacturing, but updated or retargeted for the software environment. Poppendieck suggested these categories for software waste:
Partially Done Work
This is the equivalent of excessive inventory in a manufacturing environment. On-going but undelivered work may not seem like a major issue in software. There are no warehouses or boxes of parts. There is however still a significant sunk cost.
Work has been done and not been delivered to customers. We have expended cost and realised no value. This can be managed by keeping teams focussed to completion, avoiding the temptation to be driven by each new crisis.
Extra Features
Creating and delivering work which does not generate customer value is waste. Even if the work is good quality and successfully delivered. If it is not valuable to the customer, it is not effective for the business. Being clear about customer value can help mitigate this, along with clear roadmap planning and fast feedback cycles.
Relearning
Relearning involves the repeated learning of a piece of knowledge. It may be by a single individual or by multiple individuals. We may be returning to a past problem we worked on ourself. Or we may be visiting a problem where someone else had understood the problem. Each time the knowledge is re-acquired we incur an expense. Relearning can be mitigated by effective collaboration, communication and knowledge management.
Handoffs
Handing work between teams and individuals slows progress and disrupts flow. When work is transferred, there needs to be scheduling. This means we need to queue and wait for the recipient to be available. Handoffs can be addressed by using cross-functional teams which are able to perform all or most of the tasks within a single team. Focussing on self-managing teams against working as individuals is also powerful here.
Delays
Any loss of time in a development process is wasteful. This occurs most often when decision making is separate from the team. If the team lacks autonomy, they must summarise information, transfer the summary and wait for approval. There is often a degree of further delay as clarification is sought from managers far from the problem. Delays can be mitigated by keeping decision making at the lowest viable level.
Task Switching
Task switching occurs when individuals are asked to work on multiple work areas in parallel. There is a context for each work item and it takes time for an individual to move back and pick up the old work. Each item being worked on in parallel reduces agility and efficiency. Task Switching can be avoided by keeping clarity about priorities and ensuring that everyone has the same understanding of these.
Defects
Defect reduction can be addressed by “building quality in”. This refers to ways of working that focus on quality up front. Avoiding adding defects to the product is far more effective than making a product with defects and trying to detect and address them later. Clear testing approaches are key and a common understanding of what is needed to declare work to be complete.
Leave a Reply