One of the most frequently asked questions is ‘what are the right metrics for an Agile project?’
My response usually is something like this:
Borrowing from a popular quote from George Box, the famous statistician, ‘All models are wrong. But,
some are more useful’, I would say that all metrics are wrong, but some are useful!
Like with many other practices that have degenerated to just the externally visible ceremonies – aka
cargo cult practices – with the understanding of the meaning lost in transit, metrics have also become in
most teams, something that is created for someone else.
Organizations expect fancy dashboards and status reports, that, they feel, can help them control the
outcomes in the project.
So, when teams are forced to show progress in terms of what the management wants to hear [which is
usually only the good news], some teams use the watermelon metrics model!
Like watermelons, these metrics look green from the outside, but when you cut deeper, it is all red
inside.
The teams know the pain points and the real status of how things are. But, forced to project a green
status, they end up stretching themselves to somehow meet the deadlines, that they were not involved
before being made public.
So, do we need metrics for Agile teams? If yes, how should they pick up the metrics?
Remove all vanity metrics.
Vanity metrics can be things that give a good feel for the person who wanted it! These could include
Volume related: such as # hits, # builds etc
Superficial: such as KLOC, # tests added, # deployments
These may give a feeling of a lot of work done, but will miss the point on whether value is being created
for the customers
Instead, focus on metrics that can hep increase the quality and collaboration in and across teams.
Another category of metrics could include those that only exist to support or justify the bureaucracy
that has degenerated over time in teams and organizations.
This could include metrics that were defined a long time ago – surely for a reason – but are no longer
relevant, as technologies or processes and practices have changed over time, and, possibly become a lot
more complex
What is the solution?
Focus on identifying actionable metrics.
This will help you identify multiple categories of metrics based on who will see this and how they would
use this.
For example, for individuals, even simple code quality metrics, or build stability metrics could provide
the near instant feedback to help write netter code.
For teams, the burndowns or projected end date would let them figure out strategies to meet their
commitments. Other metrics such as turnaround times, cycle times etc would let them identify actions
for improvement.
For managers and senior leaders, it could be about impediments and their impact – on dates and the
cost of living with those impediments.
So, by stratifying the metrics based on target groups and making the metrics most useful to those
closest to the generation of a metric, one can not only avoid the watermelon metrics, but also make
metrics more meaningful.
What metrics do you find most or least useful? Share and let us discuss.
Trackbacks/Pingbacks