Measuring Agility
In coaching organizations as part of Odd-e, we eventually reach a point where we try to figure out how to measure agility. This is understandable: the organization spent time and effort on becoming agile, and so it makes sense to try and figure out where they are now.
I’ve always referred to the Agile Manifesto and the 12 Principles behind the Agile Manifesto for this––to check whether the organization is living the values and following the principles. The manifesto and principles define what Agile is, therefore we can use those to assess ourselves.
One major challenge to this is that Agile is realistic but unattainable. We do not have a checklist of what it means to be perfectly agile. Defining any measure such as a scale of 1–10 or maturity models would only hide this fact. Reaching the most mature level, or getting a 10, only means we can no longer improve, which is definitely not the goal. We can be agile today, but we can definitely be more agile tomorrow, and we can continuously become more agile than how we were before.
Lately I’ve tried to look at things from a different perspective. As a coach, I usually recommend to start with Scrum to manifest agility. Scrum is essentially a set of rules that you play in––you need to come up with your own approach as long as you follow the rules. This makes Scrum easy to understand but difficult to do, as you must figure out how to do your work. Since we start with Scrum, perhaps we should look at measuring our agility from the perspective of Scrum:
- Are we doing Scrum properly to manifest agility?, and
- Are we taking advantage of this agility?
The first point asks if we are “doing things right”. Can we actually ship every sprint at the very least? One of the main ideas of Scrum is to have a “Done” increment of the product after each sprint. And once we have that, we then try to make our Definition of “Done” stronger as we go along. I’ve now come to view the Definition of Done as the primary improvement tool in Scrum: having a stronger Definition of Done results to being able to ship your product increment every sprint, and releasing every sprint allows you to adapt and change direction every sprint, which leads to more agility.
The second point builds on the first: now that we do things right, are we continuously “doing the right thing” and maximizing our investment returns? This reflects how we make use of our Product Backlog––is it simply a list of things that we should do, or is it dynamic and changes every sprint? A colleague of mine came up with Terry’s Agility Index to describe this, and while it started as a joke, it ended up as something profound.
These measures are pretty general in themselves, but should be more concrete than simply the Agile Manifesto and the 12 Principles. And like with Scrum, it is best to leave it to the organization to translate this so something of value, so the organization can own it and change it when necessary.
I’m interested to know how you’ve tried to approach measuring agility: what did you come up with, what were the challenges that you’ve faced, and how was it taken by your organization?
