They didn’t work then, they don’t work now. I was aghast at the title of a recent McKinsey article, “Yes, you can measure software developer productivity.” I started to respond, but after reading thoughtful responses from colleagues Kent Beck and Dave Farley decide to wait, until Jennifer Riggins weighted in with her outstanding analysis. What follows is an excerpt from my recent book that I hope reinforces Kent, Dave, and Jennifer’s messages.
One more time
At lunch with staff from a prominent Agile software tool vendor, one person was touting their tool’s ability to rollup team velocity to the executive level. I was so aghast at this use of velocity I wrote a blog post titled “Velocity is Killing Agility” (Highsmith, 2013). Not prepared for the reaction—the volume crashed my website.
Was James Michener a better writer than Ernest Hemingway because his books are longer? Or because he could type 20 words-per-minute faster? Makes sense—right? Assessing the effectiveness of writers based on per-unit productivity (activity) measures makes no sense. If your job is to write Java code “words” rather than English (or French or Polish) words, similar productivity measures make no sense either.
Productivity measures are meant for tangible things, such as how many widgets a machine can manufacture in an hour. Productivity measures were never designed to access intangibles such as ideas and innovations. But measuring intangibles is hard and measuring tangibles is easy, so naturally people gravitate to what is easiest, even when it’s wrong. Better to have some measure rather than nothing—right? No! Give me a fuzzy metric of something valuable (an outcome) rather than a precise metric for something unimportant (an output) any time.
Unfortunately, productivity mania has followed us into the Agile age. Too many organizations are still obsessed with productivity measures that limit their agility. Velocity is lines of code dressed up in new clothing. As many times as Agilists 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 it gets us in trouble every time.
In Jerry Weinberg’s quality workshop, he would ask, “What would you pay me for an application that I guarantee has no defects that calculates the biorhythms of Stanly Jones, who worked in the Ohio department of motor vehicles from 1945 to 1964?” The value of that app, for 99.99% of people, would be zero, so who cares if the development team delivered 50 stories per iteration or three?
When we are exploring new products, services, marketing programs, or business models, productivity measures make even less than no sense. Innovative ideas, valuable stories, high-quality code, reduced cycle times—these are better measures of success in today’s environment. Evaluating two teams who are working on two different new products in two different business functions, using two different technology stacks, based on their story velocities makes as much sense as typing speed makes Michener a better writer than Hemingway. There has to be a better way.
(C)2023 Jim Highsmith