Perusing the current December 2012 edition of PMI's "PM Network", there's an article about measuring and reporting on Agile projects that needs to be just as agile, as well, Agile.
With the growing popularity of Agile (in fact, it has become so popular in my opinion that the most popular one, namely Scrum is what I refer to now as the the McDonalds of Agile), that the Agile PM has such a gamut of metrics to post against their project that the balance is now to pick what's best while still allowing rapid delivery.
These two are often in contradiction with each other so balancing both is hard. I know first hand as it has often been a difficult balancing act in my experience. So I'm wondering for those out there running Agile metrics, how have you found the balance?
A "Branch" on this post re Agile Metric Arena: I have observed Development Managers and Directors attempting to insitute Agile approaches having a real problem in particular with the approach of estimating Agile projects using Story Points (o any other "realtive" mesaure of effort) - because - even if they Do go ahead and start evaluating performance based on "The Group" rather than "The Individual", they can't standardize among the groups to consider and evaluate **comparative** performance. So - they either continue to use something like "Ideal Days" - OR - they try and indentify a "baseline" development effort (one that really happened) and the Story Points assigned to that - - -
Agile purists tend to ignore (or simply argue that "it can't be done") - i.e., the need for management to be able to measure productivity. This is a big issue that needs more work to address how this could be done - whether it is with use of Function Points or some other methodology/approach/process.
I agree with Andy. The right type of metrics will only ever add value. The 'wrong' metrics will slow things down and people will come to resent the data capture. Don't think about the common phrase 'what gets measured gets done' and instead think about what metrics would actually be helpful to you and the team.
You can always introduce metrics slowly and constantly review them to scrap the ones that aren't relevant or that don't get consulted. Saving Changes...