Reduce waste in software development with 3M model: Muda, Mura, Muri
Last updated: November 17, 2023 Read in fullscreen view
Recommended for you
- 01 Apr 2022
Ishikawa (fishbone) diagram in software project management - 24 Nov 2022 Genba Genbutsu Genjitsu (3Gs), (Go to the Genba & see for yourself!)
- 09 Sep 2022 Kaizen, Kaikaku and Kakushin – what’s the difference?
- 02 Feb 2022 Yokoten: Best Practice Sharing from a success
- 21 Dec 2023 Top 12 Low-Code Platforms To Use in 2024
Muda - The Waste of Non-Value-Adding Activities
Muda, the standard 7 wastes: Over-Production, Inventory, Motion, Defects, Over-Processing transport & Waiting.
Literally translated, muda means “futility; uselessness; wastefulness,” though more broadly it refers to the seven common types of waste seen in business:
And don’t forget the human wastes: Talent, Focus and Communication waste.Defects in the end product
- Time lost due to waiting for processes
- Non-essential movement
- Excess material or equipment inventory
- Excessive production
- Redundant processes
- Unnecessary transport or handling of materials or products
Mura - The Waste of Inconsistency, Unevenness and Variability
Mura, losses due to variation.
Mura refers to “unevenness” or “irregularity” -- specifically, irregularity in production levels. Consistently stable levels of production allow a business to effectively implement maintenance procedures and reduce worker fatigue, while uneven production leads to more frequent equipment failures, employee burnout, and increased difficulty in accurately planning for the future.
Variation can be found in every part of the process:
- Processes that are not well balanced
- Fluctuating customer demand
- Machine breakdowns and delays
- Variation created by downtimes (man/machine)
- Repetitive actions of a person or machine that deviate from the baseline
- Impact of defects
- Insufficient staff present
- Not having the right materials and tools
Muri - The Waste of Overburdenning
Muri, losses due to the overloading your people and/or machines. Forcing the development team to work extra hard to meet the deadline will end up in overburdenning (無理 muri). Overburdenning will only make the organisation fragile rather than sustainably agile. Overburdenning in software development, as in manufacturing, will end up in low quality product. But unlike in manufacturing, low quality software are not easily noticeable to managers and even to customers because you have to dig through the codes to find out the rot. And because of this reason deadline limits organisation agility. Organisation should shift its focus and start investing in infrastructure for release on demand so that their customers or Product Owners can release the software to production environment anytime they need it with a single click of a button.
“Beyond one’s power” is an especially potent definition for muri, as it refers to employees or equipment that have been overburdened. The dangers of muri should be obvious. Employees who are overworked experience greater levels of burnout, and a lack of situational awareness caused by exhaustion can be extremely dangerous, particularly in industries that rely on heavy machinery or dangerous chemicals. Likewise, equipment that’s stressed too much will break down more frequently, and can create wholly new hazards for anyone nearby.
All lean companies strive to eliminate muda, mura, and muri, but it’s important to explicitly identify all sources of waste before deciding on a removal plan. Muda, mura, and muri feed into and directly impact one another, and it’s all too easy to decrease muda only to see muri increase. Or for mura to decrease while muda increases. To avoid a painful, drawn out game of inefficiency whack-a-mole, muda, mura, and muri should be combated simultaneously, using a holistic approach that trades quick, superficial fixes for entrenched improvements in business processes.
If you overstretch or overstress people and machines, you create safety risks, quality loss and even health problems.
Typical causes
- Workplace organisation that has not be thought through
- A lack of (preventive) maintenance, unreliable machines
- A lack of reliable processes
- A lack of the right tools
- Insufficiently trained staff
- Over-planning of the production equipment
- Excessive fluctuation of the customer demand
Muda in Software Development
Which forms of waste cannot be adapted to Software Development?
Eliminating something is way easier than understanding a system, finding the waste and acting properly. Again, acting properly.
Muda is an activity in the process which doesn’t add value to the product. When we are talking about waste we are actually referring to muda. According to the Toyota Production System muda falls into seven major categories.
Over-processing: Addition of feature not considered in the project scope (Gold Plating)
This kind of waste is generated when we add things to the product that the customer didn’t ask for (aka Gold Plating). Developing these things takes time and money, they unnecessarily increase the complexity of the system, and increase the possibility that new problems will appear. For example, your customer asks for a simple website and you deliver a complete JavaEE solution when a static website have done the trick.
Example:
- Too strict rules for development (processes, methodology,…).
- Very complex workflow in JIRA that everyone only skips when the request is done and they want to close it
- Too much focus on measurement and reporting
- A status meeting has no value to the customer.
For example: After having met the requirements, the project manager or the developer works on further enhancing the product, thinking the customer will be delighted to see additional or more polished features, rather than what was asked for or expected. The customer might be disappointed in the results, and the extra effort by the developer might be futile.
Tip: Avoid extra features by validating assumptions about value and needs in short feedback cycles.
Over-production: Too much nice-to-have and could-have features
Over-production happens when an organization does not understand the change in the customer demand and therefore produces too much or too early. In other words, you have an existing product, and you are adding features to this product, but they no longer provide value to your customers or they cannot use them at all. For example, adding features to a website which runs only in Internet Explorer.
Nice-to-have and could-have features do not add value at this time, but probably turn to must-have in next phase (i.e. 5 years later when the customer base is growing rapidly). It is the theory of Kano analysis for product strategies.
Example: Production of more and more functionalities without ongoing customer feedback.
Transportation: Lack of communication, lack of transparency and ambiguity are key problems in software project
The transportation waste is generated when materials are moved around the factory. Moving materials is expensive and dangerous. Fortunately, we don’t move materials around the office, but we move a lot of information through several unnecessary middlemen. This can take some time and in the meantime the information can change, get lost or become obsolete. For example, you cannot talk directly to the other teams or cannot download logs from the production system.
Example:
- Distributed information changes all the time
- Sending bugs between systems when searching a solution, sometimes without further analysis (sometimes you hear the developer's justification: now it’s not my issue….)
- Frequent focus switching between many parallel projects and parallel tasks, broken focus
- Passing the request between many subcontractors (internal and external)
Tip: Handoffs can be minimised, even eliminated, by building autonomous, cross-functional teams that have everything they need to go from concept to cash.
Motion: Wrong tools, wrong methodologies are the implicit matters behind project delay
Motion is very similar to transportation, but it is about the people. This waste is generated when the people have to make rounds in order to get the job done, they are using the wrong tools, don’t have all the information to do the job, or get reassigned. For example, you have to use gedit for javascript development, because your company doesn’t want to buy you a more suitable development environment.
Example:
- Sending a completely finished request for approval back and forth over and over again
- Meetings that do not add value
- Distraction from work
Corrections: Defects, Bugs and Technical Debts are kinds of wastes
In other words: defects or bugs. They are the result of poor code quality (bug) or poor software specification (defect). Fixing the issues in the system won’t eliminate this kind of waste. Instead, it will hide them, or transfer them to a different place. This kind of waste is a well known sign that something is wrong in the process. The right move here is to find the place which is malfunctioning and fix it.
Inventory: Unused deliverables, useless artifacts are kinds of wastes
Inventory waste is generated when the output of a phase cannot be immediately used by the next phase, or the finished product cannot be delivered to the customer. For example, your architects are writing you studies about what the system should support next year, but the developer teams cannot pull anything from them for months.
Example:
- Analysis that we will need in the future (maybe)
- Done but not deployed code
- Unused tools and licenses
- Preparation of extensive or duplicate documentation that is not used
Similarly to partially done work, context switching can be addressed by limiting work-in-process. Context switching due to unplanned work (for example, incidents) can be tackled by learning about (and addressing) the root causes of incidents (post-incident reviews). Context switching can also be a symptom of poor prioritisation and this can be addressed by prioritisation frameworks (cost of delay).
Waiting
Waiting is a very tricky one, because its quantity is highly subjective: I would say that I’ve been waiting for a long time now after waiting 3 or 4 hours, but my girlfriend would say this after 20 minutes. By definition, the waiting waste is generated when a team member is idle, because he or she cannot do anything at all. For example, testers are waiting for the new package installation to be finished. They cannot do anything (testing, improvements, etc.), because their system is being installed. Pulling a work item from a different queue doesn’t make too much sense either. The installation will definitely be finished before they can finish the pulled item, and finishing the item will delay the real testing work. So they stay idle instead.
Example:
- Waiting for the subcontractor team to start addressing our request
- Waiting for prioritization results
- Waiting for the availability of the test environment
- Waiting for accesses
- Waiting for release
Muri in Software Development
Mura in Software Development
Mura refers to inconsistency, unevenness or unbalanced demand situations in the system. For example, the workload is usually not that high at the beginning of the project, but always becomes high at the end of it. Unfortunately, Mura is a bit underrated, but it is important to know that it generates Muda and Muri. For example, when the demand increases, most of the people start to make mistakes (correction waste), forget important details (transportation waste), have to report more (administration waste) or get reassigned (motion waste). When the demand is lower, we tend to pile up work (inventory waste) or do what we think is necessary (over-processing waste).
Conclusion
Muda is a result of Muri and Mura. Blindly removing Muda will maybe remove the symptoms, but not the root causes.
By applying the principles of Muda, Muri, and Mura in software development, teams can reduce waste, avoid overburdening, and achieve a more even and predictable workflow. This leads to improved efficiency, quality, and employee satisfaction, ultimately delivering better software products.
Explore more on these topics
Guest Blogging: The Definitive Guide
