Re-Thinking Eliminate Waste

 

This artile is within the context of software development. Eliminate was in the physical world makes sense because you can see it. Virtual worlds are different.

This was originally posted in February 2017.

Re-Thinking “Eliminate Waste”

A common refrain in Lean-Manufacturing is “eliminate waste.”  However, this can be very misleading when applied to software development (product or IT).  There are two main reasons for this.  The first is that manufacturing involves trying to refine a single repeatable process.  The other is that because manufacturing exists in the physical world (whereas software is more virtual) waste is more easily seen in manufacturing than in software development.   There have been many disagreements about what “waste” is in software.  Is planning, documentation and design waste?  Clearly, we need some of these but many people argue that they are waste.  Going for as little as possible is likely not the right answer. 

In Principles of Product Development Flow, Don Reinertsen said “If you only quantify one thing quantify the cost of delay.”  Although he was stressing the importance of quick delivery, it provides a clue to shift our focus to delay in delivery.  This, of course, is affected by many things.  But the causes of delay in the realization of business value are insidious in software development because most delays create additional work to be done (typically in the form of rework).  By eliminating delays, we eliminate much of this additional work – freeing up time for creating more value. 

So yes, we do want to eliminate waste, but we do so by eliminating delays in workflow, feedback and business value delivery.  Focusing on delay instead of waste shifts the conversation from “is this waste?” (something people often disagree about) to “is this delay causing problems?” (something we can mostly agree on).  Consider this – few people will argue for delays.

Re-thinking “Last Responsible Moment”

The mantra to make decisions “at the last responsible moment” has a similar challenge.  Many people won’t agree on what that last responsible moment is.  However, if we consider delays, what we want to do is to minimize the delay between making a decision and acting on it.  The greater this gap the greater the risk of it being a poor decision. Let’s consider requirements as an example.   Getting all of the requirements up front is clearly too early – as implementing some will affect others.  Shifting from “the last responsible moment” to “when will I need the information this decision entails?” will improve the timing of the decisions involved.

The Key Is Alignment

It is straightforward to begin a transformation to Agile at scale.  But after the initial training and kickoff, it quickly becomes more of a “how do I shift people’s mindsets?” than a “what do I do?” challenge.  We’ve all seen Agile “transformations” where people kept the same mindset adversely affecting real change.  Shifting mindsets is necessary to achieve alignment across the organization. We need to consider not just the end-result (eliminating waste and making decisions at the right time) but what questions can we ask that will have people work together better.  As has been said by many people in different ways “we will get better answers when we have better questions.”  The power of better questions is illustrated by Jonas Salk’s comment – “what people think of as the moment of discovery is really the discovery of the question.”