This is the ninth in a series of posts on dealing with the impediments raised in “Agile Antipatterns Are Easy to Spot, Hard to Change”. The ninth antipattern discussed in the post is…
9. Emphasizing process metrics over actual project outcomes
It’s been my experience that some software development teams like to track metrics — sometimes, lots of them. Other teams track few, if any at all. Which approach is better?
Sadly, neither. When you track many different metrics, you’ll get mixed messages. Some of the measurements will tell you that the team is doing well while others will claim the opposite. On the other hand, if you track few if any metrics, there is no objective measure of the team’s past performance or its future potential.
Yet the biggest problem with most metrics is that they are inwardly focused. The team is measuring its output artifacts with an eye toward improving itself. Yet what matters most is the outwardly-focused, end-user experience.
If the software will be used inside the company by a business group, productivity improvements are a valid expectation. If the software will be sold to paying customers, increased revenue and market share are the most important measures.
How much time do you have?
The other challenge with metrics is that they are only as useful as the time you’re willing to devote to gathering, analyzing, reporting and tracking them. If your data collection approach is haphazard or unstructured, your results will be useless, or worse, misleading.
In the end, team performance is a function of outcomes not metrics. Don’t fall into the trap of forcing the team to meet contrived metrics at the expense of meeting user expectations.
I don’t mean to imply that metrics are a waste of time. They can be useful in your continuous improvement efforts if you use them wisely. Try following these simple guidelines:
- Identify what is most important to the team and to the business.
- Define the fewest possible metrics that can be used to evaluate #1.
- Recognize that metrics are situational; they will change from project to project.
There’s more to software development than delivering high-quality software on time. It has to be the right software. Inwardly-focused metrics can’t tell you if the software is right. Only an outward focus on the end users can do that.