How Do You Measure Agility?

The more information you provide to someone, the less likely they are to look at it.

Have you ever experienced this exact scenario? I’ve spoken to executives from different markets who all agree that, while they want better visibility into how their organization is performing, too much information tends to muddy the water. We also live in a world addicted to “Big Data” and “Data Science” in an effort to make sense of the chaos.

That being said, as organizations work to adopt business agility, they are curious as to whether or not they are in fact improving. Is this “Agile Initiative” we are investing in actually helping us or just becoming another fad framework that will ultimately get someone fired once we go back to what we used to do?

Measuring in an Agile environment can tend to be frowned upon, depending on who you ask. “The primary measure of progress is working software.” And, while there continues to be merit in those words, we could ask: is the software of high quality? Was it delivered faster than we have done it previously? Are we increasing our efficiencies? Are we more adaptable to change than we used to be? The primary measure of progress might be working software, but it is not the primary measure of agility.

While keeping in mind that every organization is different, we continue to reach out for those great ways of measuring ourselves, all the while balancing lean concepts and encouraging empowered productivity over malicious obedience and what I call “Gamificationism” of the metrics. So how do we get answers to the questions posed above? How do we measure in such a way that the outcome promotes the right questions continuing to enable a truly Agile environment?

It’s critical to have metrics that actually mean something and this can come in many forms. Some metrics are completely empirical in nature and have absolute paths to improvement. Other metrics are more “smell test” in nature. They require simply taking a look and giving it your gut reaction based on perception of the observed. One is not more useful in nature than another; simply different. The context of use is specific to the organization you are in and the nature of your workflow/teams. Some folks simply don’t know where to start. You might ask, “which ones are right for our organization?” “What options are available to us?” “When would it be most appropriate to put these measurements in place?”

If I’ve piqued your interest, download the recording of my webinar entitled Agile Metrics That Mean Something to gain answers to these questions and more.