[kailuowang]

The purpose of measuring productivity is to manage it. There are two categories of factors that decide the overall productivity: the factors within the developers (capability, motivation, etc) and the factors outside the developers (tools, process, support, etc).

True, it's hard to objectively measure the overall productivity using a universal standard, but it is relatively easier to measure the productivity fluctuation caused by the external factors. Velocity measurement in Agile practice is mostly for that end.

For the internal factors, the best way, and arguably the only effective way, to manage it is probably to hire good motivated developers. I think most top level software companies have learned that.

[lifeisstillgood]

This is true - to an extent. Scrum screams out to measure relative story points, and never provide the data for "management" purposes. But even the same team estimating in succession will face external pressures - and if those pressures will be alleviated by gaming story points, they will. This catch-22 had me - I truly think the only way is to report only an estimated finish date. Any public posting of velocity eventually filters into a management by velocity - because that's the only metric management has. And we are back on the same old loop - we can have a measure of productivity as long as we do not use it in any manner as a measure of productivity.

Add to this I don't think scrum has become setup to take this to its logical conclusions - agile/scrum has been sold as a fairly fixed methodology, not as a means to get some relative metric out of teams and use that in a series of experiments to achieve productivity improvements. And even if it were, the major wins we know and can prove work (quiet conditions, minimal interruptions, trust, respect, time for reflection and education, are a long way from being accepted by today's enterprises.

In short there is no silver bullet, and while agile looked a magic bullet it just turned out to be plain old lead.