In the context of Lean manufacturing, there have been numerous studies that estimate that the proportion of value adding time in a production cycle is around 5%. The other 95% is deemed to be waste. These studies also conclude that by far the biggest waste is overproduction.
Anecdotally, I think it is a very similar story in software development, although my fear is that the proportion of value adding time is even lower.
Waste takes many forms, but broadly speaking, effort as a team or in a company fall into three areas:
1. Valuable Effort – Value-adding activities, these activities cost time and money, and there is a consequential opportunity cost but they add some value. However, the value may be able to be realized more effectively.
2. Obvious Waste – Non-value adding activities that are evident. These activities cost time and money (and opportunity cost) but add no value to the product being created. Examples are vacations, breaks, or sickness.
3. Valueless Effort – Non-value adding activities masquerading as valuable effort, they cost time and money and have an opportunity cost, but add no value to the product being delivered.
Waste Reduction is Not Your Goal
I will be covering the wastes in more detail but it is very important to note that waste reduction NOT be the focus of your efforts. Waste identification is a supporting activity for the Theory of Constraints, and any efforts to improve a part of your system that is not the bottleneck is a waste in itself. But identifying waste can aid in your efforts to improve your bottleneck, so it is a great tool to support your other activities.
The Seven Deadly Sins
Lean identifies seven wastes (recently adding an 8th waste)
8. Wasted Potential of People
'There is nothing so useless as doing efficiently that which should not be done at all,' Peter Drucker.
Overproduction is considered the worst of the wastes and ultimately it is this particular waste that is the basis of much of the Agile Manifesto for Software Development. This is why systems thinking is a topic that is always a concern.
Agile is founded on the premise that at the start of the product we know the least, and lack of flexibility is the biggest constraint in the success of software development. Traditional methods plan, create, test, and support endless features that are unnecessary. The cost of this waste is unfathomable and big enough to trigger the Agile movement and challenge the way we work.
Overproduction was also the primary waste identified in the book 'The Goal' by Elivahu M. Goldratt and Jeff Cox. If you haven’t read this book I would heartily recommend it. The book is a great primer for the Theory of Constraints and for understanding the thinking behind Lean.
Planning is Waste?
But Agile has not completely fixed this problem, and in my experience development teams regularly and persistently develop unnecessary features. With many teams choosing to work without sufficient time spent on planning, story writing, or prioritizing, and without consideration for whether the work they are doing adds any value now, or more significantly adds the most value next.
Road mapping, planning, and story writing are often incorrectly perceived as 'waste' and the avoidance of waste is used as a justification to get back to coding on something. Oftentimes, something that is likely not valuable and almost certainly not the most valuable activity to be worked on next, is a far more insidious waste than the planning could ever be.
Features 'not needed yet' are implemented on the basis that it will save time later, or features are added because 'We know we will need it later' – (seven words I dread to hear.)
We work to look or feel busy, and in our minds we translate activity as being productivity, when there is little correlation between the two in the context of software development. In software, creativity, problem-solving, and planning are far more valuable efforts than unfocused coding.
'Give me six hours to chop down a tree and I will spend the first four sharpening the axe.' - Abraham Lincoln.
In most cases, features have no value until they are in the hands of a user and being used for a productive effort. So any activity not spent getting the next most valuable feature into the hands of a user quickly is just waste.
Writing extra features that are not used or rarely used extends the production time but brings little or no value. And it also compounds all of the other wastes because, by its nature, production of something of little value needs to go through the system, thus exposing an unnecessary feature to all the other wastes.
When you next start work on something ask yourself this question: 'Is this the next most valuable activity for our customer?' If you cannot confidently answer that question, then maybe you need to spend more time planning so you can spend less time coding something that is not needed.
In software, the biggest risk to any project is that it will be canceled or obsolete prior to being used by your customers. This may sound obvious, but if a project is canceled, ALL of the features are waste. All that effort produced no value for anyone. And all that time, effort and money could have been spent elsewhere. So getting your product right, is only good if you get your product delivered.
Delivering value to your customer quickly is the best way to mitigate the risk of your efforts being wasted, and 'done' is not really done unless it is in the hands of a customer and actually being used for a productive purpose.