What comes to mind when you think of the word "waste?" I'd wager a ten spot it wasn't something pleasant. Rather, something to be pushed to the curb, rinsed down the drain, or thrown into a hole in the ground and buried. Even the sterile waste from technology projects has a high "ick" factor. If Josef Oehmen and Eric Rebentisch of MIT’s Lean Advancement Institute put the amount of time, money, and resource wasted in corporate product development at 77%, how can there be anything good about waste?
Now think of something you value quite highly - a piece of fine jewelry, mastery of a sport or musical instrument, or your home. Have you considered how many resources may have been "wasted" to bring those highly valued things into existence? Shiny diamonds get that way by cutting and throwing away pieces of the original, mastering a sport or a musical instrument involves years filled with bad moves or cringe worthy sounds, and a significant amount of material was used and discarded while building your home.
When organizations consider implementing one of Agile's many formalized methodologies or frameworks, the idea of eliminating waste is a prominent promise that helps close the sale. Cutting out waste means saving money and saving money means increasing profits. Unfortunately, this promise is frequently delivered to the agile teams as: "All waste is bad. Get it right the first time." This message doesn't support exploration and discovery. It doesn't allow teams the space they need to find innovative solutions in what Stuart Kauffman called the "adjacent possible." And it certainly doesn't encourage the iterative development of numerous minimum viable products that build upon each other and lead the way toward the delivery of quality products.
The message I work to reinforce is: "Expect to throw stuff away, especially early on." By itself, this isn't enough to overcome the many negative connotations around waste. What is needed is a fundamental re-framing around the activities that have resulted in something one expects to throw away. A couple of questions are worth asking. What value is anticipated from the activity? What are the potential positive effects of having engaged in an effort at risk for ending as waste? Pursuing a goal of zero wasted effort is a fool's errand. What we want to reduce is any effort that doesn't add value. If 40 hours were spent exploring a technical option "only" to find out that it wasn't a viable option in the long term, that throw-away 40 hour effort may just have saved 400 hours of developer time spent trying to make it work. And had the less-than-optimal long term option gone to market, the expense of supporting the early wrong decision could make or break the product, perhaps even the business.
Skilled agile practitioners have a strategy for monitoring the value of any project related efforts:
Establish definitions of activities that create value. By identifying the intent behind the effort and acknowledging the value, the team is better positioned for focusing on the goals and objectives of the activity. Discovery, exploration, risk assessment, even fun can be worthwhile justifications if it is clear they add value to the overall effort and end goal success.
Identify efforts that are wasteful, but nonetheless necessary, and work to minimize the effects of these efforts. Transitioning from a design sprint to actual production work often results in a lull in activity as the design team works to communicate to the production team what needs to be done. Similarly, when production work is handed off to deployment, support, and maintenance teams.
Identify clear signs of waste. Gold-plating (over-engineering), lack of a product vision or road map that causes the agile team to "make it up as they go along" and react to the customer's reaction, infrequent opportunities for feedback (both inter-team and with the client), or time-tracker cards that attract dozens of hours of nondescript time.
From a lean product development perspective, Oehmen and Rebentisch describe eight types of waste. I've included my additions and comments in parenthesis.
Overproduction of information
Two different groups creating the same deliverable
Delivering information too early
Over-processing of information
Over-engineering of components and systems (Often referred to as Gold-platting.)
Working on different IT systems, converting data back and forth (The use of one-off tools rather than leveraging the capabilities within the organization's suite of tools.)
Miscommunication of information
Large and long meetings, excessive email distribution lists
Unnecessary hand-offs instead of continuous responsibility
(Unacknowledged project dependencies, such as the effect of re-architecting system components, on client projects.)
Stockpiling of information
Saving information due to frequent interruptions
Creating large information repositories due to large batch sizes
(Withholding opportunities to review work and solicit feedback.)
Generating defective information
Making errors in component and architecture design
Delivering obsolete information to down-stream tasks (Insufficient feedback opportunities, delays in communication due to competing project responsibilities.)
Correcting information
Optimization iterations (Rework)
Reworking deliverables due to changing targets (Design ambiguity, client decision instability)
Waiting of people
Waiting for long lead time activities to finish
Waiting due to unrealistic schedules
Unnecessary movement of people
Obtaining information by walking up and down the hallway
Traveling to meetings
References
Kauffman, S.A. (2003). The Adjacent Possible, A Talk with Stuart A. Kauffman. Retrieved from https://www.edge.org/conversation/stuart_a_kauffman-the-adjacent-possible
Oehmen, J., Rebentisch, E. (2010). Waste in Lean Product Development. Lean Advancement Initiative. Retrieved from http://hdl.handle.net/1721.1/79838
Image by Peggy und Marco Lachmann-Anke from Pixabay