#75-Lean Principle: Eliminate Waste

In part one of my series on Lean, I examine the concept of eliminating Muda, or waste.  I will show this in the context of manufacturing and software development, to compare and contrast the two.

Transcript

Lean principle: Eliminate Waste 

Lean began as a manufacturing paradigm. It was focused on the way that workflow and machines were arranged on a factory floor when physical products were the goal of production. But recently it has been clear that the principles that drive lean are also applicable to software development in profound ways. 

In manufacturing waste, or Muda as the Japanese call it, can be defined as the following: 

Excessive production: making more than you have need for at any given point in time.

Delays in flow, where one part of the process is waiting excessively for another part of the process to complete. 

Having to repeatedly move raw materials and parts from one part of the process to another. 

Unsold inventory, which used to be seen as an asset to a manufacturer but is now seen as waste because it must be stored, protected from damage, and yet provides no immediate revenue. 

And finally defects: mistakes in manufacturing that require repair and rework. 

Taiichi Ohno, the creator of the Toyota Production system, was focused on the manufacturer of automobiles at the time. He pointed out that the overproduction of one part of a car, an engine for example, when the rest of the car is lagging behind uses up space and resources and requires storage costs without delivering value. His idea was to build things just when they are needed so that they can be immediately converted into value.

In software these same concerns exist but in a slightly different way. 

Overproduction means putting features into the software that customers do not value, and therefore will never use. Many products have features that are buried beneath layers of menus and are never needed by anyone. 

Delays in software are often due to excessive ceremony around production. Developers must wait on approval for their design plans, must excessively validate requirements that are unclear, have poor devops tools that slow down builds, and so forth. 

Although software is not physical and therefore does not need to be transported from place to place, there are handoffs in the process and each time the development team has to hand something off to, let's say, testing then there is a risk of lost information and the introduction of errors. 

Unsold inventory in software means features and other system elements that have not yet been completed and so cannot be delivered to a customer. This would include half-built code, user stories that are stuck in a process, or backlogs that are too large to be effectively managed. 

Defects in software are often called bugs, and recently I focused on the early detection of defects through the process called shift left. 

What both physical production and software development have in common is the concept of customer-centric value. Anything that is built, planned for, designed, or in any way takes the attention and effort of the team but does not deliver customer value is waste.

So, how do we avoid these problems? I will address that in an upcoming episode.