It started with an assertion that any thing that doesn’t add customer value or delays delivery of customer value is waste.
That sets up a binary decision: tasks either provide customer value or they are waste. I’ve noticed that when people first start mapping the value stream for software development, they tend to assert that management is all non-value added work.
In addition to value-added and non-value added work, I think there’s another category: “non-value added but necessary.”
Non-value added but necessary tasks are tasks that don’t directly add value to the customer but enable delivering value to the customer. Sometimes these are the tasks and functions that enable the business to stay in business like accounting, or payroll, or management.
That’s not to say that there isn’t waste within those functions, there certainly is.
But no one likes to hear that they are adding no value. When people hear that, they tend to feel defensive. People who are feeling defensive are less like to be able to take an clear-eyed look at how they can best improve the system (and it certainly doesn’t do much to build the type of team communication needed for effective teamwork) .
Having a category of “non-value added but necessary” gives a way for people to examine the work that isn’t directly on the software development value stream without focusing so much on justify their existence. Then the are more likely to see where they are doing tasks that don’t enable creation of value and shift their focus to work that does.
We need to look at “value” from the customer perspective, certainly. We also need to look at value from the viability of the overall organization, and at work that isn’t directly related to the product but creates the conditions for creating value.