Estimated time for this course: 15 minutes
Suggested Prerequisites: None
Upon completion you will:
Ohno’s work captured the essence of what is called Lean manufacturing in the West. He wrote that the first step in applying the Toyota production system is a simple idea: identify and eliminate waste. Rather than inventing a new process, first eliminate the waste in the existing system. There will be a dramatic improvement in productivity and, more importantly, the process will fundamentally change.
Removing waste will lay your process bare. Now you can now make explicit changes to it and then inspect and adapt accordingly. Changing your process before eliminating waste is a bit like rearranging the deck chairs on the Titanic. In Scrum, we often treat waste as Impediments. It is important to identify, track and remove it.
Ohno broke Muda down into 7 categories. They are broken down in the tabs below.
In Process Inventory
This is the greatest sin of waste according to Ohno. In manufacturing work in process is typically associated with cued inventory. Identifying in process waste gave way to the Just In Time supply strategy. In Scrum in process waste is called Work in Process, often shorthanded as WIP. The waste occurs when a team works too many product backlog items simultaneously. This slows the team down an prevents them from moving any one item to done quickly.
Making more of something than will actually sell is a form of waste. In farming this is like growing more product than the market will consume. That extra production is just pure waste. Money and resources are tied up in product, not helping to add value to the organization.
In new product development this waste happens when teams don’t follow the 80/20 Rule. (The idea that 80% of a project’s value is in 20% of its features.) It is the Product Owner’s responsibility to correctly Assign Business Value to backlog items so the team does not work on features that have relatively low value. A strong Definition of Done will also help prevent team members from doing more work than is needed to produce a valuable feature.
Often organizations fall in love with process itself and forget about the product. Over-detailed documentation, unnecessary management overhead, and excessive reporting are some common examples of process waste. Organizations have legal and functional reasons for requiring process and documentation but it is important that these activities help create business value and aren't simply outdated or misguided.
Every step a worker has to take to move a product from one machine to another is waste. There’s going to be some, but it should be ruthlessly minimized.
A famous example was when Toyota took over the NUMMI automotive plant from GM. One gigantic multi-ton machine was fifty or so feet out of its optimum position. GM just worked around it. Toyota got every employee in the plant to lift the machine with only human muscle and move it those fifty feet. Stopping production for the couple of hours paid off by removing those minutes of waste inherent in the previous layout.
Transportation waste isn't limited to a production line. In an office environment, transportation waste often takes the form of poorly coordinated hand-offs between team members.
This is often associated with context switching, or what most people refer to as Multi-Tasking. Research shows that context switching creates incredible amounts of waste as the brain sets aside the knowledge needed to perform one task and accesses what it needs to perform the next. Choose a job, complete it and then move on. The slide above has a break down of how much waste is created switching between jobs.
On a production line, if a machine is waiting for another machine to finish its job, each minute of waiting is waste. In Scrum, if a Team isn’t well cross-trained, a lot of time can be wasted waiting on a Team member to complete a job no one else can do.
The key to eliminating waiting is minimizing dependencies on expertise, information or materials. Poor communication can create delays if a Team member has to wait on a critical piece of information. In manufacturing, if a critical piece of hardware hasn’t been delivered, the entire enterprise might have to wait until it arrives.
Software developers are familiar with this form of Muda. If a Team isn’t creating daily clean code, a lot of time can be wasted going back to fix bugs. We cannot stress strongly enough the importance of addressing bugs quickly and on the same day they are discovered, and if you’re doing continuous integration, on the same day they are created. Research has shown that fixing a bug a week later can add a factor of 24 to the time it takes to fix a bug. In other words, fix a bug today, and it will take an hour, fix it in a week it will take three 8 hour days.
Regardless of the industry, going back to correct mistakes creates waste. Errors can be limited by building quality control into the development process so that issues are discovered and corrected at the point of origin. In Scrum, the speed of development is driven by the quality of the work. Do it right the first time and eliminate the waste of re-work in the future.