Fighting Waste With DevOps: The 7 + 2 Types Of IT Waste

Much has been written about the 7 wastes found in manufacturing and office environments. These wastes were originally identified in the Toyota Production System over 50 years ago. However, there is a common lack of understanding when it comes to the best use of these definitions and their application in the world of software development, deployment and subsequent service. First let’s define the original 7 wastes (aka Seven Deadly Sins):

1. Overproduction – Creating more code, features and functions than the customer needs at the time. Anything we build that the customer is not ready to “consume” is considered over production. Taichi Ohno, the father of the Toyota Production System, referred to overproduction as the worse of all the wastes because it creates surplus inventory which clogs the workplace and hides problems. Many people find this idea counterintuitive because it feels right to create more than what is needed in order to get ahead of demand. In reality, this rarely turns out good – the customer changes requirements while a lot of energy is spent managing loose ends.

2. Over-processing – Creating features beyond what the customer has requested, in other words, doing more work than is required. This is a cousin to overproduction but focuses on excess functionality as contrasted to excess product. Another example is redundant troubleshooting steps. How much functionality requested by the customer is actually used? Building additional functions “just in case” takes resources and, in some cases, hinders ease of use.

3. Defects– Defects are, well, defects: any work product that is not 100% correct and complete contains defects. In the world of DevOps, it goes without saying that most of the work is iterative so, of course, all the work done contains defects until it is “done done!” That being the case, the point is that work that is passed to a subsequent process with a known preventable defect is clearly waste, creates rework (which is usually performed by another person) and should be eliminated.

4. Over-engineering – Making things more complicated that necessary.  This is also related to over production but focuses on excess complexity versus excess production. When brilliant developers start creating, there can be a tendency to over do it – introducing bells and whistles that delight developers but confuse end users.

5. Inventory – In a factory, inventory is all the work in process (WIP) and finished goods sitting on the shelf waiting for customer orders. In DevOps inventory is all the partially done work. An example of WIP inventory is the backlog of open tickets. This work in process may be on hold, waiting for information from someone, or just waiting in the queue. The waste associated with inventory is 1) the re-start costs associated with picking up a partially completed piece of work, 2) the time it takes to manage it and 3) delays in discovering quality issues.

6. Transportation – Transportation refers to movement of product. In DevOps, this includes movement of code as well as endless emails and IM’s which seem to linger on for far too long. Excessive review and approval processes fall into this category as well. An example is moving a service tickets from team to team before it reaches the correct destination. The key impact here is the movement of attention that this causes. Searching for information could be considered another form of transportation. All this activity is considered as waste because it does not technically add value to the product or service.

7. Waiting – This waste addresses all the waiting that occurs by both people and product. If a person is waiting for anything (code, information, etc.) before they can do their job, that wait time is wasteful. It’s not that people sit and twiddle their thumbs: what most of us do is thrash to another task – but that introduces additional transportation – the waste just mentioned.

8. Motion – This is waste of the movement of people and includes walking and shuttling about from meeting to meeting or down the hall to the copy machine. In many cases, I think the “waste” of movement is offset by the benefit of walking around, stretching your legs and clearing your head. Of course, excessive movement means very little work is getting accomplished.

The Ninth Waste: Unused Creativity – For years, this additional waste has been added to the list of traditional wastes. This is the lack of engaging all employees in an ongoing improvement process. This is perhaps the most tragic waste as it means that the unlimited potential of people, creativity, is at worst unused or at best underutilized. In DevOps, people can be so busy with today’s firefighting that it seems there is little time for creative problem solving.

Technical Debt – Speaking of firefighting, in the world if IT, there is often such a rush to address the current problem (e.g., server down, firewall breach, app patch) that we seldom find the time to identify the root cause of problems and instead treat symptoms by layering “temporary” fixes on top of existing code. As time goes on, we have built layer upon layer of workarounds (sometimes not documented) that make finding and fixing future problems and subsequent code changes that much harder. Technical debt ultimately adds to the waste of over engineering.

In the next post, we’ll explore how to use these definitions to drive continuous process improvement in a DevOps environment.

- About The Authors

Mike Orzen