I have attended an interesting presentation by Melanie Rose from TotalJobs organized by the great guys behind Agile Warsaw. She was telling us how they try to measure what and how they have been doing since their transition to an agile organization.
I’m not going to write here about metrics and measurements, there are sites covering it but the presentation made me think about the tools we have developed for our agile way of working and how and for what purpose we are using them.
The problem that occurs more often than it should is that once in a while someone on an agile team becomes a bit obsessed with tools. I know, most of are are geeks and we do enjoy good tools but, as everything else, they come at a price.
What I have tried with my last team was to strive to have as few tools as possible and I can report here with confidence that it was a good idea. Every so often during the retrospecitve we would take a quick look at all the tools and artefacts we had and check if the results they had produced were actually useful and then discuss if we really needed them. Good telling signs were the commitments we have taken but failed to apply to. Some of them emerged as a result of some metric or a tool but if we had failed and did not feel bad about it we could start questioning the usefulness of the thing that made us commit in the first place.
An argument to adopt a new tool and, especially, a new metric is often to prepare for the future or “just see how we are doing”. I can appreciate that but the cost of introducing such a tool is often greater than anticipated. We had the argument “but it takes only 5 minutes in the morning to tag the tasks” but nobody predicted in advance that discussing the outcome will chip away a lot of time during the retrospection and we wouldn’t actually learn anything immediately useful. We could have said that it might become in the future but you know what? It haven’t. True, sometimes you have to spend more time analyzing the past because you haven’t measured something in advance but we were not good in predicting what would eventually become useful so it was a good call to drop everything not usefull immediately.
So, the short version of this post is: be aware of the total cost of any tool or metric or a tool you are using and double-check if you are getting useful and practical information out of them. Otherwise, after a while, you might find your agile stiff and a slave to a process.
As a reminder: Agile Principle 12: Inspect and Adapt.
Update: An article targeting specifically agile metrics on InfoQ.