Across the board, industries need to embrace modern workflows to keep up with the speed of startups. And out of all the various methodologies, I find the “lean methodology” to be the most intriguing of them all. It’s a unique combination of pragmatism and a higher purpose.
Lean methodology descends directly from the Toyota Production Systems (TPS), which is based on a philosophy of eliminating waste to achieve efficiency in processes. It relies heavily on the mindset of “just-in-time,” making only “what is needed when needed, and in the amount needed.” In software development, this means only developing the features your clients need, and only when they need them.
To emphasize the point and stir some creative juices, let’s look at the Japanese concepts of muda, mura and muri, and how this applies to being lean when we are building and shipping software.
Muda, mura and muri
Muda is the “waste” we are working to remove that is directly hurting efficiency. Waste is any activity that doesn’t create value, in the form of the products and services we offer. As every engineer knows, spending half the day in meetings is a painful waste of time.
Mura is “unevenness,” referring to any variance in the process itself or the output generated. In software development, “mura” causes unpredictability that makes it impossible to embrace a “just-in-time” mindset. If the quality of a new upcoming feature is uncertain, then additional time and resources will have to be reserved for quality assurance and bug-fixing efforts. It’s better to know upfront what you are going to get, how long it will take and what the cost will be.
Muri is “overburden,” which happens when we demand the unreasonable from our team, tools and processes. If we want to deliver a specific feature just-in-time, then we must allocate the appropriate time and resources. Giving our engineering teams too many simultaneous tasks, or failing to give them the tools necessary to succeed, will only lead to disappointment in time, quantity, quality or cost.
Forms of waste
Diving deeper into muda — what I consider the cardinal sin of lean methodology — here are the forms of waste we should always be on the lookout for:
- Overproduction – Producing more than is needed, or before it is required. Besides unneeded features, we often over-allocate computing resources, especially in non-cloud environments.
- Transportation – Moving work items between stations, facilities or environments wastes time and energy. While digital assets are often cheap to transmit, deploying an artifact to a specific environment is often a time-consuming and risky process.
- Inventory – These are the raw materials kept for future work. It’s important to limit inventory as much as possible. Cut half-developed or untested features that aren’t bringing value to customers.
- Motion – Moving people or tools around wastes time and energy. There’s always room for improvement here. For example, COVID-19 has brought new light to the overhead of commuting and traveling for business trips — this is a good time to reflect on the massive amount of waste for many organizations.
- Over-processing – Producing a product that is beyond what the customer needs or is willing to pay for. Over-processing often means spending too much time on quality, over-optimizing on performance in areas that just aren’t required.
- Defects – Poor quality forces a product to be reworked. Going back to fix a bug, or redesign a feature, are the classic examples of this in software.
- Waiting – In software development, we waste too much time waiting for the next step in the process. This often happens because the person responsible for a task doesn’t have the proper support, access or tooling.
- Unused skills – Underutilizing people’s talents, skills and knowledge is a significant source of waste. While not every single ability somebody possesses may be useful, there are bound to be hidden gems that can help with significant business challenges.
Eliminating unnecessary waste
Let’s pause for a moment. Certainly, there will always be muda in software development. That’s why lean methodology divides waste into two types: The first type involves activities that are necessary to deliver the product, even if they don’t add value to the product itself; the second type of waste is about activities that do not add value to the product and are not necessary to deliver the product. This second type is what needs to be completely eliminated.
(A good example of type 1 waste is data collection. While data has no direct customer value and can even pose security risks, it’s necessary in order to make better decisions. COVID-19 has pushed many people into digital workflows they weren’t used to before, and there’s simply no way to be successful as a business in this new paradigm without access to contextual, rich data.)
To eliminate the type 2 waste we should all be concerned about, the lean methodology relies heavily on jidoka, colloquially referred to as “stop the line.” This means that whenever a person or machine identifies a problem, they have the autonomy and authority to cease that activity immediately.
This helps avoid waste accumulation that manifests in low-quality products or drawn-out processes and bureaucracy. One of the best things an organization can do for productivity is empower people to make important decisions without a ton of overhead. In DevOps, the core of the “you build it, you own it” mindset rests heavily on jidoka.
The efficient use of resources and elimination of waste has allowed the Japanese car industry to rise to the top of the global market with affordable, high-quality cars. There’s a lot we can learn from the lean methodology there and apply it to software development. Look out for both small and substantial waste of resources around you, whether it comes from unnecessary meetings or outdated workflows. DevOps and agile development are two great examples of the lean methodology that I encourage all digital businesses, especially those dealing with internet scale, to look into seriously.