We are just people - continuous work in focus for 8 hours is not something we are capable of. We have to make short breaks, socialize, drink coffee. Don not worry you are not causing any wastes or... or do you? If you do, it is not because of a short break or coffee. I will tell you who should be blamed for the wase in your company - its Tim Woods! (The article is inspired by the Lean production which is also known as Toyota Production System).
It is a creature that may live in your company in whole or partially. To be honest it is just an acronym used in Lean vocabulary which may help you to memorize the 8th popular wastes in manufacturing. To have a solid start let's formalize what waste is. Shigeo Shingo, one fo the pioneers of the Toyota Production system believed that waste is one of the greatest threats to business viability. The common definition of waste in Lean is :
The use of any material or resource beyond what the customer requires and is wiling to pay for.
Toyota has identified seven major types of non-value-adding waste in business or manufacturing processes . In the early adaption of Lean in the US and Europe in the 1990s the 8th waste was added (which made TIMWOODS from TIMWOOD). Let's enumerate them with synonyms in square brackets which are closer to software development from Implementing Lean Software Development From Concept to Cash :
You may think that
Ok but Toyota is producing cars, right? I am doing software you know... you can not drive with your software home...
I was a little bit skeptical when I firstly encountered the "Lean" word. I was thinking more or less the above but then I started to dig. I thought that it could not be that Lean has so much traction across many different industries if it was not something valuable. I am glad I was digging. Let's take a closer look to each of the waste with examples that I lived through. Try to think about this waste now before reading more. Can you identify some of them at your work?
Do you remember Chinese whispers game (for my polish colleagues it is głuchy telefon)? It is like that. With each handoff the whispered sentence gets more and more malformed. Or better said: with each handoff some knowledge is lost. If you want to reclaim that knowledge additional communication is required to resolve the ambiguities.
Originally in Toyota Production System relates to excess inventory. Excess material causes longer lead time, aging, damage to goods, transport and storage costs, as well as delays. In addition, additional resources hide problems such as production imbalance . In software development this relates to partially done work. Partially done work means that there is a raw material (for example undeployed changes, unfinished places - TODOs) that waits for us (software engineers) to be taken and used to create truly done work.
Any motion that employees have to perform during their work like looking for, reaching for or stacking parts etc are waste. In software development this maps to task switching. Solving complex software problems requires focus and time. Switching between tasks in not only distracting but often hinders both tasks, which naturally causes that none of them is completed. Multitasking may be a step before inventory waste [partially done work].
Working with accordance with DevOps culture means that the software developers will have to task-switch to handle urgent production issues. However this "waste" provides great motivation to deliver defect-free code, so the team can concentrate on new development . We mustn't avoid task switching at all costs, rather we should monitor the necessary task-switching and keep the limit low.
This simply means that workers have to wait for the next processing step, tool, supply, part, etc or just having no work of lot processing delays. What is more: according to  developers make critical decisions about every 15 minutes and it is naive to think that all the information necessary to make decisions is going to be found in a written document. The decision can be made quickly if the engineer has a good understanding of what the code is supposed to accomplish and/or there is someone in the room who can answer any remaining questions. We also have to pay attention some processes we are running before we force ourself to wait for a build, CI process etc.
Did you experience a situation in which the development team decided to add something extra because it was just easy to do? Did you experience a situation where business ordered a feature and did not use it for a very long time (or even not at all)? I did many times. For some of you it may be hard to start to think about this as of waste, but one of the Toyota Production System creators Taiichi Ōno emphasized that overproduction making inventory that is not needed immediately is the worst of the seven wastes of manufacturing  If there is not a clear and present economic need for the feature, it should not be developed.
Use Kaizen technique of 5W (5 x Why). It is simply about asking why 5 times. Here is a trivial example:
Let me start with original Lean waste - Overprocessing or incorrect processing takes unneeded steps to process the parts. Inefficiently processing due to poor tool and product design, causing unnecessary motion and producing defects . This can be related to writing to much code. I am a little bit obsessed with this. The best code is not to code at all. When there is code there are bugs, you have to maintain it, you have to write tests which are the only proof that your code is not guilty and that still is not enough. Who will tests your tests? I still love to write code but it has to be precise, concise, exact - more like a Math formula. Last but not least consider my beloved quotation:
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupéry, Airman's Odyssey.
In Implementing Lean Software Development  authors write about relearning which simply is rediscovering something we once knew and have forgotten.
Every well-designed system should include self-defense tests which do not let defects into the system at all levels of the Cohn's tests pyramid. Even so the software still fails - it just proves how complex the software nowadays is. Cohn's pyramid originally have 3 levels. Currently at work my team automates at 5 different levels: unit, unit - acceptance (at this level we consider behavior as a unit), integration, UI, main user journeys. Moreover we still do exploratory testing. Some parts are so complex that we still fail but we fail fast. It happens rare so we treat it more like an opportunity to learn rather than a failure. You may ask - putting so much effort to create extensive automated testing is not itself a waste? Shigeo Shingo says that "inspection to prevent defects" is absolutely required of any process, but that "inspection to find defects" is waste . It is like the old good saying: "Better prevent than cure".
Its about losing time, ideas, skills, improvements, and learning opportunities by not engaging or listening to your employees. This really happens at a daily basis in many places. This can be viewed from a different perspective - if you know something that can be beneficial to the process but for some reason you decide not to share with that knowledge/skill you are the source of waste.
Applying Lean in software development can be a powerful technique and works extremely well with agile software development manifesto. I have mentioned a lot of techniques, methods to handle this wastes. This only proves that lean identified real waste and we - software engineering society - are constantly trying to find the best ways to eliminate them (even without being aware that we want to reduce waste that was classified a long time ago). I hope I inspired you to start fighting waste symptoms that you already have in mind. You can start with waste and then look into quality, value, speed, knowledge, people which are also considered in Lean. To help you with that I really recommend the referenced books - you will not regret reading them.
1 DevOps Handbook John Willis
2 The Toyota Way: 14 Management Principles from the World's Greatest Manufacture Jeffrey K. Liker
3 Implementing Lean Software Development From Concept to Cash Mary and Tom Poppendieck
4 The Pragmatic Programmer, 20th Anniversary Edition David Thomas, Andrew Hunt
5 The lean startup Eric Ries