One topic I’ve heard mentioned again and again in the agile community lately is “agile metrics” – the measures we use to determine whether our agile teams are successful. In the past, I’ve told both students and clients that identifying agile performance objectives is extremely easy — happy customers; good, working software; happy teams — it’s that simple.
Choosing what we measure (our metrics) to confirm we are meeting our performance objectives, however, is not as easy. Customer satisfaction surveys, product sales, feature value, cycle time, weighted defect rates, employee retention rates and even fists-of-five can be good measures, but the right metric and scale are often guided by the specific situation and organizational context. So, we typically ask questions like, “Is this a good metric for us?”, “What threshold defines success?”, “Can we collect it?”, “How should we report it?” and “How will we use it once we know it?” in order to establish agile metrics for a given organization.
Establishing agile metrics in this way is great for measuring the success of an agile transformation or agile business unit. But, unfortunately, it has its limits beyond measuring agility. Meeting your agile benchmarks doesn’t necessarily mean that your organization is achieving its strategic business goals. Stated differently, delivering good, working software is a great engine, but without a transmission, wheels and a good driver steering your high-performance vehicle around the track, a good business strategy can still end in a wreck.
What, then, do we do? The answer is that we work our way backwards — from business objectives and business metrics to agile team objectives and performance metrics that enable the business objectives to be achieved — much like we do in Balanced Scorecard strategic planning. This is called “cascading”.
For example, if business strategy dictates that our organization “Become a market leader” by increasing market share from 20 to 40% in two years, then agile metrics need to measure our ability to meet this business objective. Perhaps we intend to gain market share by delivering new features faster than our competitors, in which case, measures like cycle time, process efficiency and frequency of delivery are worth considering. Or, perhaps the way to gain market share is to improve product quality, in which case customer satisfaction, usability, and weighted defect rate become more important. Either way, the business objective is driving the agile metric.
As you can see, there are definitely measures that are generally more valuable to collect than others, but there’s really no one magic metric that captures it all. So, there’s no point in searching for one, or in claiming that there is one.
And, we can’t assume that meeting our agile performance measures will ensure business success. Because, while your ability to deliver good, working software may be at an all time high according to your agile metrics, your celebration of your hard-won agility may occur at the same time your organization is on the verge of shuddering its doors — if you’re not careful to incorporate business objectives.
