(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.

One thought on “In response to Forget Productivity by Jim Highsmith

  1. Having read both points of view and with some equivalent experience in working with funding and purchasing of services in the delivering ‘public good’, where the same issues arise and apply to commercial and corporate objectives of the public sector, there is I believe a space somewhere between the notion of an outcome and an output, which relates to the premise of working smarter not harder. This is as an age old issue where the measuring of success should be a balance of quantitive values, (GDP/units per quarter/lines per day) in comparison to the qualitative benefits realised in delivery and design that take account of a smarter and arguably, overall a more successful product, where a more productive workforce/cost benefit analysis/value for money argument can be achieved. The creative tension in this space leads to both an opportunity for innovation and invention, but also if outputs purely predominate it can be prohibitive to delivering the principal objectives and lead to the classic symptoms of presenteeism or expending budgets for the sake of targets. How to make an assessment of qualitative data and units and measures of success is arguably more subjective and unpredictable and even less tangible until the results are evaluated upon delivery. It sounds as though more of the same healthy arguments extend to programming.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s