There are two kinds of waste. First kind of waste is features which are not being used and nothing is done about it. Eliminating waste in that scenario might even mean removing the feature – at least it won’t require maintenance. Second kind of waste is quality related which team does due too much hacking – bug fixing, manual deployment for hours, etc..
Achieving zero waste is practically impossible, but the point is not complete elimination of it. The point of measuring is to see the trend. If waste keeps increasing over time it’s pointing to issues with quality or a team working on wrong things.
I used to work on a system which let’s people setup surveys online (like survey monkey). One day a customer asked us to implement ability to copy questions because they wanted to run the same set of questions months after. Without further thinking my Co-founder rushed into satisfying customer and dev team to implement it. One customer, not enough understanding of the use case – harmful feature. It took the team only 1 day to implement the feature. However, in the coming months we were constantly coming back to this code to fix it when new data fields are added to surveys.
On a surface waste in this scenario is work done to maintain it. Which can be fixed by making copying mechanism less dependent on specific data structure. However, if we look at the first kind of waste and at the patterns of usage for this feature – the whole feature is a waste. Customers didn’t want to copy questions, they just wanted to run THE SAME questions at DIFFERENT TIME. To eliminate the waste would be to remove the copy feature and built ability to schedule another round of questions for a single survey instead.