Measurement and management

I've been following a thread on the Agile Project Management mailing list on measuring productivity. One of the posts makes reference to the oft-repeated axiom, "if you can't measure it, you can't manage it." Sounds perfectly reasonable, doesn't it? It also seems perfectly reasonable that you would want to manage, and therefore measure, the productivity of software developers and software teams. But as several people in this thread point out, there is really no good measure of software productivity. We all dismissed the notion of measuring lines of code a long time ago - at least I hope. Agile methodologies encourage the measurement of team velocity - how many features, story points, or estimated task hours the team completes in a particular iteration. I would argue, as did some in the discussion, that this measurement is properly used only to estimate the workload for the next iteration - it's "yesterday's weather". If it's used by management over the long term to measure team productivity then human nature dictates that the team will skew the estimates to generate a positive outcome.

I would argue that the best measurements for success are (1) customer satisfaction and (2) profitability. While it's true that true customer satisfaction can't be measured until the end of a development project, the product owner can provide interim measurements of satisfaction - as each iteration is delivered.