By now, most technology professionals and those in technology-adjacent roles are at least familiar with Agile, the Scrum framework, Kanban and Lean. What some may not realize, however, is that a number of these frameworks and techniques to maximize efficiency are not as modern as they appear; they’re not born out of challenges unique to building software but come from the world of auto manufacturing.
Starting in the mid-1940s, a Japanese production engineer at Toyota named Taiichi Ohno developed the Toyota Production System (TPS) as the company aimed to compete with American automaker Ford. Ohno was under tremendous pressure to deliver; to do so, he sought to completely eliminate waste and inefficiencies in their manufacturing process.
A large part of TPS is centered around identifying and eliminating muda, the Japanese word for “uselessness” or “wastefulness.” Though we’re not often working with raw steel or assembling combustion engines, software development teams can find parallels in the challenges Ohno and his team faced with some of the struggles we see when building technology solutions.
Below is a list of Ohno’s seven forms of muda, as well as the eighth waste introduced in the 1990s, that teams in any type of organization should learn to identify and seek to eliminate, though I’ll largely speak to them in terms of software:
1. Transportation
In manufacturing, moving around raw materials and components more than is absolutely necessary can cause undue damage, not to mention the associated cost of the additional work involved in moving said product around — cost that customers would not directly pay for.
In a software setting, this manifests itself by moving parts of a user story between teams or by constantly moving team members themselves from project to project, creating confusion and a lack of cohesiveness.
To help mitigate this, build cross-functional teams with “T-shaped” contributors (individuals that have a breadth of knowledge in several areas but a depth of experience in one or two) that can deliver value from design to delivery without being dependent on contributions from outside the group. Having a team that solely works on APIs, rather than integrating those individuals across all product teams, creates dependencies for other teams who need changes to backend services. Work items then have to be moved from team to team before they’re complete and usable.
2. Excess inventory
Having excess inventory in a manufacturing setting is fairly easy to see: too much raw material, piles of complete products stockpiled and waiting to be shipped to customers, or equipment that’s sitting around collecting dust.
Ohno believed that “the more inventory a company has, the less likely they will have what they need.” This applies to software, too – a bloated backlog can make it difficult for teams to clearly see what is important and what can be deferred to the next release, the next quarter, or even the next product. Even in a world where each story is meticulously crafted and likely to be a great idea, the effort needed to refine and manage those stories can become overwhelming and time-consuming.
To combat this, organizations should empower their product owners to say “no,” or at the very least, “not right now.”
3. Motion
Unlike transporting goods from place to place, motion refers to the repetitive or excessive movements of the body in a manufacturing setting, which includes looking around for parts, constantly reaching for tools, lifting, bending down, etc. For the culinary-minded out there, chefs will set up their mise en place (“everything in its place”) at their stations before starting the dinner service to make sure they’re not running around a bustling kitchen looking for clarified butter.
Those of us in office jobs are not necessarily on an active shop floor, but it is still important that everything needed to complete a task is readily available. The time spent looking for a design comp or architecture diagram is time that does not directly bring value to the customer, so it is time wasted. Great documentation (with a consistent place to keep it) and team norms that include a Definition of Ready can help combat the feeling of having to “reach” for what’s needed. Additionally, try to ensure teams are co-located and sitting together so they’re not chasing each other around the office.
4. Waiting
In manufacturing, waiting around is often caused by unevenness in the manufacturing process itself – if a step in the process is much quicker than the previous step, that second station will constantly be waiting around for work to come to them.
This is also true in software development. Often, quality assurance professionals spend the first few days of a sprint waiting around for developers to commit code so they can begin functional testing and moving the work closer to done; that time isn’t necessarily wasted (they could be fine-tuning their test plan or refactoring their test scripts), but it would be better spent on activities that directly deliver value. In the absence of having true cross-functional team members that could both write code and test, teams should look to break down user stories to much smaller vertical slices of functionality so that QA gets their hands on them sooner.
Another way to eliminate this particular kind of waste that can be implemented right now is to be respectful of each other’s time, especially when it pertains to meetings. This is as easy as showing up on time so that attendees are not waiting around; if you’re facilitating the meeting, prepare and circulate the agenda ahead of time so that you can make the most of the time spent together.
5. Overproduction
This is closely related to excess inventory, but overproduction is the practice of manufacturing product before it is ordered or manufacturing more product than is ordered. One tenet of lean manufacturing is “just enough, just in time,” as a means to reduce cost and lead time, but this overproducing “just in case” philosophy will often lead to having excess product that needs to be stored – again, any cost that customers would likely not directly pay for, including the cost of storing goods that may never get sold or used.
One way we see this in building software solutions comes from under-informed “genius design,” where beautiful blue sky features are designed without having done the research on how real people will use them; when it they’re finally released to production, they don’t fulfill the needs of the user. The projek202 methodology seeks an understanding of what users value ahead of time and align that with the needs of the business to build a solution that satisfies both parties. That way, the development teams don’t spend time building features that end up going unused.
6. Over-processing
Doing more work or adding unnecessary or redundant steps in the manufacturing process can lead to over-processing, where the costs of these additional efforts can add up quickly. This is also true in software, where over-processing can take many forms, from unnecessary refactors to over-engineering solutions or adding extra features that weren’t asked for or well-researched.
For developers, the concept of over-building is sometimes referred to as YAGNI (“you aren’t gonna need it”) and developers who love solving technical problems rather than user needs tend to fall victim to this. More code written means more bugs and a greater amount of time for each new developer to ramp up as they join the team. Making good architecture decisions and reducing over-engineering is a skill that needs to be practiced over time.
The best way to combat this is understanding the requirements through the eyes of your customers. A capable product owner should be able to understand the business intent of the initiative, marry that to the needs of the customers, then ensure the development team members have what they need to understand both of these perspectives. Writing strong user personas and keeping them visible to the team is a clear reminder of why work is being done in the first place.
7. Defects
In manufacturing, as in software, defects occur when things aren’t working as intended or don’t meet the quality standards set by the organization or expected by the customer. In both industries, this leads to reworking the product or scrapping it entirely if it’s irreparable.
The best solution to addressing defects is to prevent them in the first place by not allowing them to move through the workflow. As a developer, writing unit tests is a must and a quick functional test before sending it off to QA goes a long way. Bugs will still slip by, though, so a more pragmatic approach is to inspect your process to make sure the type of defect is not repeatable. One tool I like is the Five Whys exercise: when a problem occurs, ask yourself and those involved why it happened until you get to an answer that is outside of the organization’s control, and address the problem at the level before that. Instill countermeasures to prevent it in the future, rather than implementing a solution to deal with a symptom, then standardize that countermeasure as a part of the process.
8. Underutilized talent
Although not initially a part of Ohno’s TPS, avoiding underutilized talent and wasted potential is as important as avoiding the other forms of muda. This type of waste is more of an organizational one, rather than one that comes from inefficiencies in the process. When management roles are separate from those performing the work, it is the responsibility of the former to organize, plan, budget, and be held ultimately accountable for the product, and it is up to the latter to execute the plan as outlined. Ohno said, “Standards should not be forced down from above but rather set by the production workers themselves.” By not fully utilizing the expertise and experience of those closest to the work, process improvement and creative solutions can be left on the table. Ultimately, this can affect the bottom line of the initiative.
This type of waste can also take the form of employees being assigned tasks or put into positions well under their skill level. A senior engineer with decades of experience would not only be bored making copy edits in a content management system, but his or her talents would be much better suited to architecting a new platform, spearheading a product launch with a new technology, or teaching or coaching others within the organization.
How do we eliminate these eight types of waste?
For teams using Scrum, there is a built-in avenue for inspecting and adapting the process in the form of the sprint retrospective, and that’s a great place to do so at the micro level (but not exclusively during the retro).
However, for teams to feel comfortable openly discussing process and product improvement, they must feel empowered by the organization to do so. This starts with a commitment from leadership to trust those closest to the work, to foster a culture that encourages speaking up about problems when they’re found, and to have enough agility in the organization itself to pivot when the need arises.
Ohno believed that “having no problems is the biggest problem of all.” I would encourage any team to not only look to solve waste issues in their process when they come up, but to actively seek them out.
