James Michener was a better writer than Ernest Hemingway because his books are longer. James Michener was a better writer than Ernest Hemingway because he could type 20 words-per-minute faster.
Assessing the effectiveness of writers based on productivity measures makes absolutely no sense.
If your job is to write code “words” rather than English (or French or Spanish) words, judging your work based on productivity makes no more sense.
Productivity measures are meant for tangible, consistently repeatable things, such as how many widgets a machine can manufacture in an hour or how many shirts a person can sew in a day (even the effectiveness in these situations can be challenged, but I’ll leave that for another day).
Productivity measures were never meant to measure the creation of new sources of value such as ideas and innovations. Measuring intangibles like original value is hard, while measuring concrete tangibles is easier, so naturally people gravitate to what is easiest, even when it’s wrong. Better to have some measure rather than nothing—right? As I’ve said before, give me a fuzzy metric of something valuable (an outcome) rather than a precise number for something unimportant (an output) any time.
Unfortunately, productivity mania has followed us into the creative digital age. Too many organizations are still obsessed with productivity measures, which limits their success when using agile delivery to drive business innovations. The new agile metric is velocity, but it’s just lines of code dressed up in new clothing. As many times as agile experts say “use velocity as a capacity indicator, not a productivity measure” velocity inevitably sets teams against teams and undermines both value and quality. Velocity is a quantity measure (output) and they get us in trouble every time.
So, forget productivity—go with value, and cycle time. In one of Jerry Weinberg’s workshops he asks the question, “What would you pay me for an application that calculates the biorhythms of Stanley Jones who worked in the department of motor vehicles from 1945 to 1964?” The value of that app, for 99.999% of you would be zero. So who cares if the development team delivered 50 stories per iteration? Or three?
Good ideas, valuable stories implemented, high-quality code, and shorter delivery times— are better measures of success in today’s environment. Evaluating two teams who are working on two different new products in two different business contexts using two different technology stacks based on their story velocities or lines-of-code makes as much sense comparing Michener-Hemingway based on the weight of their books.
I would have written a longer article, but I’m trying to be less productive these days!