Value-stream mapping is a useful tool that forces tech teams to focus on activities that add the most value for the customer, rather than those that are recommended in some textbook, or that employ a hot new technology a senior person happens to want to learn, or that use a development method that will look good when reporting to the CIO. However, too often advocates of this laudable technique have been operating on long-discredited ideas of what economic activities "add value" and what ones do not.
The subject of economics itself grappled with this problem for a couple of centuries. In the 1700s the French physiocrats held that only agricultural production truly created value: the rest of us were parasitic on farmers. (Imagine if they value-stream mapped your latest web project!) Adam Smith worked to refute the physiocrats, but suggested instead that it was labor that added value to a product. But there was a problem with that idea: like the old Italian joke goes, if that were true, we would have to pay very inexperienced workers the most, since they labor far longer than an old pro to achieve the same outcome.
Economics finally solved this problem in the late nineteenth century, in what is usually called "the Marginal Revolution." Economists realized that "value" was not a substance ladled into a product by some parts of the production process, but not by other parts: instead, value arises from an act of valuation on the part of the user of a product. So, in determining whether some activity "adds value," the right question to ask is not, "Does the user of this product value the activity?" The user of the product does not value any production activities whatsoever, in and of themselves. What the user values is the features of the final product, regardless of how they were brought about. People who want to drink wine do not care if the wine is the "fruit of the land" or was created by a miracle at Cana: they care if the wine tastes good! And users of software do not care what mix of planning, stand-ups, coding, testing, and so on were necessary to produce the software: they care if it does the job they need it to do.
Thus, when we find a statement like the following (in the context of automobile manufacturing):
Value-adding operations involve the conversion or processing of raw materials or semi-finished products through the use of manual labour. This would involve activities such as: sub-assembly of parts, forging raw materials and painting body work. (5) The seven value stream mapping tools | Request PDF. Available from: https://www.researchgate.net/publication/235309659_The_seven_value_stream_mapping_tools [accessed Oct 16 2018].
We should recognize that we are being haunted by the ghost of the long-discredited "labor theory of value." If the above statement were true, consumers would value a car made by young children, who would take enormous amounts of time to complete "sub-assembly of parts, forging raw materials and painting body work," more than they would value one made by competent assembly-line workers. In fact, since most of these activities are today performed by robots, consumers should find contemporary automobiles nearly valueless.
Displaying the same sort of myopia, the website Lean Manufacturing Tools contends that:
"Only an activity that physically changes the shape or character of a product or assembly can add value. Any activity that does not change the product or assembly is waste."
But this means, for instance, thinking about how to manufacture some product is "waste": it does not "physically change the product or assembly." Advertising the product also is "waste," as it doesn't physically transform the product: apparently simply letting the product sit unbought in the warehouse is less wasteful then letting people know it exists. (See Kirzner, 1972, on the "value-adding" role of advertising.)
Similarly, in his book Kanban, David Anderson divides production activities into those that "add value" and those that are "wasteful." But activities that do not add value to a final product (and are known not to add value) are not the activities of an economic producer at all: they are called "consumption" or "recreation."
For instance, he talks about staining a wood fence for a customer:
This involved a trip to Home Depot. There was also some preparation work required on the fence: some repairs, some sanding, and trimming plants... to allow access for painting. None of these activities could be described as adding value. The customer does not care that I have to make a trip to Home Depot. The customer does not care that this activity takes time. In fact, it is annoying, as it delays the start and the end of the project.
No, unless David intends to stain the fence with air or dirt, the trip to Home Depot does not "delay the start of the project": It is the start of the project. And neither does the customer "care" that the staining takes time: the customer would much prefer that David could stain the entire fence merely by thinking about it being stained. Furthermore, the customer surely would be very annoyed if David simply stained right over the plants growing along the fence, rather than trimming them back, or failed to sand, so the stain would not take.
What Anderson is doing is simply arbitrarily designating certain costs as "not adding value" and then pointing out that the customer would like those costs minimized. But the customer would also like the costs that Anderson claims do add value to be minimized. In fact, the ideal production process takes no time and is completely costless. Until we can achieve such a process, all work that is required to deliver the final product "adds value." Any work that does not add value should not be reduced, as Anderson suggests, but completely done away with. (In fact, that Anderson talks about minimizing this work, instead of eliminating it, demonstrates that at some level he realizes that his distinction is arbitrary.)
When it comes to producing software, Anderson distinguishes between things like meetings, that are "waste," and actual coding, which "adds value." Again, the distinction is completely arbitrary. Imagine we have a software-generating AI that can simply listen to humans holding a meeting about a piece of software, and then write the code. In that case, the only part of the production process involving humans would be meetings! The customer does not "care" about the meetings, and, in fact, doesn't "care" about the coding either: the customer only cares about the final product doing what he wants it to, however the product came about. If Jesus appeared and miraculously produced the needed software product the same way that he reportedly produced wine at Cana, the users would far prefer that to any time-consuming production process whatsoever.
Short of having an AI like the one described above, or having Jesus available to miraculously produce a program, the right question to ask is, "Are the meetings being held resulting in a better software product than if they were not being held?" If they are, they are "producing value." Think about a half-hour meeting where one software engineer discovers that his colleague has already written and debugged an algorithm that he was going to spend the next week writing and debugging. That meeting was "worth" a week of coding, since the first programmer is now freed up to code something else for the next week. On the other hand, if the meetings are not helping to produce a better product, they should simply be dropped, not "minimized."
He next discusses the "waste," already mentioned above, of actually getting the product to the person who needs it, in a working state:
"The driver actually picking up the [washing] machine at the warehouse, driving at your home, and unpacking it for you is a transaction cost. Perhaps the same person, or another person, a plumber, installs it for you... All of this time and effort for delivery and installation is part of the transaction cost of buying the washing machine... The net effect of all these costs it is to inflate the final price paid by the consumer without actually increasing the value delivered." -- Kanban, p. 94
So apparently an uninstalled washing machine sitting in a warehouse is just as valuable to me as the same washing machine installed in my basement and ready to use. The funny thing is that on some level, Anderson knows he is spouting nonsense, since on the very next page, he acknowledges "It is true that the washing machine without delivery or installation is of little value..." Exactly: that is why delivering and installing it adds to its value. Since I, as a consumer of washing machines, most definitely value a machine inside my house in which I can actually wash my clothes much more than I value one sitting in a warehouse in which I cannot wash anything, then the delivery and installation steps "add value." In fact, that is why people pay for those steps to be performed.
If Anderson were correct in his claim that actually delivering products to the people who want to use them adds no value to the products, then the entire shipping industry is "waste." When Americans buy coffee from Columbian farmers, the farmers ought to stop "wastefully" shipping the coffee to the U.S., and instead just slap a label on it saying "This cofffee is now the property of Joan Smith, 123 Main St., Anytown, U.S.A." When Joan complains that she can't actually enjoy the coffee if is sitting in a warehouse in Columbia, she can be informed about all of the "waste" that has been eliminated.
Anderson goes on to argue, against Scrum advocates who believe that their daily 15-minute standups add value, "Well, if standup meetings are truly value-added... then surely doing more of them would be a good thing!" Does Anderson also think that, if a pinch of salt adds value to a dish, then adding a pound of salt must add even more value? Or that if an hour of exercise per day adds to your health, then 24 hours per day of exercise must be even better for you?
Anderson claims that "Developing more customer requirements is clearly value-adding" (216). But that is nonsense: there is no "value-added" in "developing" things: the value-added is in having them developed. All resources put into "developing" are costs, costs to be weighed against the value of having finished developing things the customer wants.
To be fair to the writers cited above, there is a kernel of truth behind their misunderstanding: to the extent some activity is going to be carried on beyond the point where it stops adding value, it is much more likely to be meetings or paperwork than it is coding. But the issue is not "meetings don't add value": it is that these meetings are dragging on too long. Value-stream mapping is a tool with great potential benefits. However, the realization of those benefits will be thwarted if its advocates continue to employ theories of value that were refuted over a century ago.
Anderson, David J. (2010) Kanban, Blue Hole Press: Sequim, Washington
Hines, Peter & Rich, Nick. (1997) "The seven value stream mapping tools". International Journal of Operations & Production Management. 17. 46-64. 10.1108/01443579710157989.
Kirzner, Israel. (1972) "Advertising: A Lecture by Israel Kirzner". https://fee.org/articles/advertising/
Lean Manufacturing Tools, "Value Add vs Non-Value Adding Processes". http://leanmanufacturingtools.org/89/value-add-vs-non-value-adding-processes/