16 June 2009
Velocity is not enough, expand the Agile dashboard …
So, one of the most powerful tools in the Agile Project Management Manifesto is the concept of velocity (and burn charts). Fundamentally, what you’re measuring is what your team is accomplishing over what it planned to accomplish. While this is a terrifically succinct and clarifying — and indeed the bottom line — with regard to delivering software, in and of itself it is not enough for a technology organization to fine-tune and improve its own operations over time. To that end, we propose other measures (while being aware of the danger of burdening a software development effort and organization with unnecessary processes). Now, we’re very aware that this can and will be heresy to many who evangelize the simplicity of the current Agile management tool stack. We feel your pain (really). BUT, to quote the old adage “you can’t manage what you can’t measure,” we propose that teams evaluate supporting metrics that can help _improve_ velocity. Further, while we propose the data gathering be continuous propose that this analysis generally _only_ occur in the midst of project execution if there is something wrong — i.e., there appears to be aberrant trends in velocity. In the coming days and weeks we’ll explore a handful of these metrics further .. for now, think of them as fuel gauge, tachometer, RPM readout, and engine temperature to the velocity chart’s speedometer.
Technorati Tags: agile, velocity, burn charts, agile manifesto, technology management
3 Comments currently posted.
David says:
sunjay says:
Hi David, thanks for the heads up on the burn chart link — fixed. Re: what is helpful/not helpful, I we’re going to roll out a few of these as the next few weeks go by. To your point, measurement for the sake of measurement, is not what we’re advocating. What we’re advocating is measurement that is used as a ‘corroborator’ or point of jump-off to analyze degradation or sudden improvements in velocity. Further, outside of *perhaps* some transparent (ahem, translucent) time tracking, ‘actual effort’ capture does not rank at the top of the list. More to come in next few days …
ALTERthought Blogs » Velocity (plus, plus) - Beefing up the Agile dashboard says:
[...] First of all, how in the world did I temporarily forget how to spell out the ‘+’ symbol ( !! – It ‘looked’ correct with two s’s – sad, really)? Earlier, I hinted at some other measures to add as _support_ to the Agile toolkit . To be clear, the raw measure that matters the most when it comes to understanding which features and whether our joint ALTERthought-client teams are delivering against plan is velocity. Period. That being said, while velocity is a good indicator of the effectiveness of the particular team/project/organization, in and of itself it does not convey rich information about the internal workings of your team and software development processes. So, velocity must be coaxed, teased, and massaged to uncover facts about the software development effort that helps satisfy a key tenet of Agile: to continuously improve. In fact, at times, velocity may be a sort of lagging indicator of what may be transpiring with regard to the process and organizational dynamics (factors the tremendously impact project success). [...]
The links for burn charts does not work. It is true, that you need to adapt what you measure based on how your project and team operates. The blob above I fear is free rein for a manager who has just been pushing for any and all measurements….I’m hoping that the info under the links qualified a bit what is and isn’t helpful.
That may be a bit defensive on my part after there was some talk about getting developers to track time on the quarter hour basis “for a while” to get a better sense of why software development take the time that it does.