(In response to Forget Productivity by Jim Highsmith and first posted as a comment to that article. I thought it worth repeating on my own blog.)
More of this “programmers are artists/crafters/code artisans — they should be treated like special snowflakes!” rhetoric — it drives me nuts!
I agree that writing code is an art and a craft. It is not like building a wall or working on a production line — it doesn’t have defined processes and actions like those.
However, posts like this ignore that simple fact that most business are in business to make money, in order to do that, businesses need to have *some* idea of when things will be delivered, or how much of a thing will be delivered by a certain date. This could be to support a marketing initiative, or because they need to order some hardware or other with a lead time that cannot be changed (and, having this hardware in inventory and not in use is waste), or simply because that’s the date that it needs to go to market.
So, let’s take the two metrics suggested as superior to “productivity” (whatever productivity is — is it story points?).
Value: Yes, let’s do the highest value items first. Let’s generate as much value as possible. “Which items are most valuable?” “How they hell should I know, we haven’t made or deployed it yet — we’ve done some focus groups and monitored our competitors, but we don’t really have a clear idea of which is the most valuable, so we’re guessing”. You’re just passing the whole “productivity” issue up the line, let someone else decide what we should build based on their own set of made up metrics and measurements.
Cycle time: Yes, this would be absolutely wonderful if we could measure everything by cycle time, but when you’re elbows deep in making a product, do you stop to care about how “big” (or whatever sized you use for a story) is to be able to compare it to other size stories to understand cycle time? (The premise being that, to gauge cycle time accurately, your work-items should be similarly sized) then you’re just back to estimating productivity again, surely? “Well, this is a small/8/dog sized story and we have usually done those end-to-end in a week/month/quarter, so expect this delivered around …”
There is no good answer to any of this. Forever more, we’re going to be working with unknown unknowns, sketchy, made up requirements and changing technical and business landscapes. I agree that wasting too much effort on measuring productivity is waste, but claiming you should measure in value or cycle time because it’s a better measure is misleading.
If I told you that a wall I have built previously was 14 bananas high and 82 bananas wide, you could probably build me a similar size wall. Whether it’s bananas, penguins, story points or inches, we’re only every using them relatively to gauge what might be based on what was — which is all estimating really is, no matter what method you use.