• IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources
  • Books
  • Resources
  • Courses
  • Podcast
  • Videos
  • Conference
  • Blog
  • IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources

IT Revolution

Helping technology leaders achieve their goals through publishing, events & research.

  • IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources
  • Books
  • Resources
  • Courses
  • Podcast
  • Videos
  • Conference
  • Blog

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

June 4, 2012 by Mike Orzen 3 Comments

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.

Most Recent Articles

  • The DevOps Enterprise Journal: Spring 2022
  • Learning Effectively From Incidents: The Messy Details
  • Putting the Ops in DevOps – An Infrastructure Story

Filed Under: DevOps Community

Comments

  1. Jaime Gago says

    June 6, 2012 at 9:32 pm

    A good example of DevOps Inventory waste could also be any code committed for deployment but in a sleeping state i.e. waiting for hands off to happen before the actual deployment begins.
    It might be worth distinguishing between automated hands-off and manual processes, then in the case of automation the code could be considered in Transportation mode vs Inventory.
    If we consider the previous statement correct (which is not a given) then this would reveal how important Automation is since transforming Information Inventory waste into Information Transportation waste is IMHO a win for DevOps. 
    As a matter of fact improving Information Transportation waste when the information is code is just another way to say Release Engineering…

    CAMS FTW! 

    Reply
  2. Mark says

    June 27, 2012 at 12:55 pm

    Hi Mike, I completely agree that employee’s talent and technical debt are among the biggest wastes in technology companies.

    Last year, after working with a client that was struggling producing output, I attempted a categorisation of wastes. It’s done without looking at the original wastes by Shingo & Ohno (or Marry Poppendiek), instead it’s from my view working with software and hardware companies. Here is what I came up with: http://www.mayberg.se/archive/eight%20development%20wastes.pdf
    Greetings from Sweden,
    Mark Seuffert

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

newsletter sign up

Topics

Tags

agile agile conversations better value sooner safer happier business business agility business leadership case study continuous delivery devops DevOps Advice Series devops case study devops enterprise forum DevOps Enterprise Summit devops handbook digital transformation dominica degrandis douglas squirrel enterprise Gene Kim incident management information technology IT jeffrey fredrick jez humble John Willis Jonathan Smart leadership lean making work visible manuel pais mark schwartz matthew skelton nicole forsgren operations Project to Product project to product tranformation seven domains of transformtion software software delivery Sooner Safer Happier teams team topologies the idealcast The Phoenix Project WaysofWorkingSeries

Recent Posts

  • The DevOps Enterprise Journal: Spring 2022
  • Learning Effectively From Incidents: The Messy Details
  • Putting the Ops in DevOps – An Infrastructure Story
  • Visualizing Team Dependencies with a Team API
  • What to Expect at DevOps Enterprise Summit Virtual – Europe 2022

Privacy Policy

Featured Book

Featured Book Image

Events

  • DevOps Enterprise Summit Virtual - Europe
    Virtual · 10 - 12 May 2022
  • DevOps Enterprise Summit US Flagship Event
    Las Vegas · October 18 - 20, 2022
  • DevOps Enterprise Summit Virtual - US
    Virtual · December 6 - 8, 2022
  • Facebook
  • LinkedIn
  • Twitter
  • YouTube
Copyright © 2022 IT Revolution. All rights reserved.
Site by Objectiv.