Kan't Ban
David T. Anderson is the guru of the Kanban movement for managing software projects.
But a competent economic analyst he is not. He divides economic 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." (The whole idea of "adding value" in production is itself questionable, but let's not go into that.)
For instance, he talks about staining a wood fence for a customer:
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, demonstrating that somewhere inside he knows 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, but, 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.
Short of having such an AI, the question is, "Are the meetings being held helpful to producing a better software product?" If they are, they are "producing value." (Again, this is not really an accurate way to speak: production processes do not ladle out little dollops of value here and there into a product.) 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.
And if the meetings are not helping to produce a better product, they should simply be dropped.
But a competent economic analyst he is not. He divides economic 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." (The whole idea of "adding value" in production is itself questionable, but let's not go into that.)
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. (Emphasis mine.)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. And 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, demonstrating that somewhere inside he knows 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, but, 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.
Short of having such an AI, the question is, "Are the meetings being held helpful to producing a better software product?" If they are, they are "producing value." (Again, this is not really an accurate way to speak: production processes do not ladle out little dollops of value here and there into a product.) 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.
And if the meetings are not helping to produce a better product, they should simply be dropped.
Coding adds *code*.
ReplyDeleteI encountered similar confusions from a former boss of mine. He wanted me to calculate our per unit cost to create our product (with the goal of determining future pricing). I determined that almost all of our expenses were overhead and labor. If we assumed that we could get a lot more work done without hiring anyone new (which was reasonable at the time because business was very slow), then in fact our marginal cost was close to zero. This did not satisfy: that’s impossible, I was advised, because in fact we had considerable expenses. But those expenses were all overhead (assuming we weren't planning any layoffs, we were stuck with our current salary levels). If you include overhead, then all of our expenses are the cost of creating the product: simply divide total expenditures by units produced to get a per unit cost. This did not satisfy, either: I was advised that I should include only the expenses directly related to the product. But why would we be paying any other employees, for instance HR, if we don't need them to make the product? In the end, I had to arbitrarily decide which roles were more "hands-on" with the product and exclude the rest. As if everybody else was just hanging around like dead weight – including myself, spending all this time on the cost per unit analysis instead of making product!
ReplyDeleteP.S. Arguably what we really needed was a model of how much new salary we would need to take on if we got so much new business that we had to hire people. I developed just such a model, but it was both complicated and highly speculative, so nobody paid any attention to it.
My sympathies, Greg!
Delete