Measuring agility: what does it mean?

All articles in our "Measuring Agility" series:

• #1 Measuring agility: what does it mean?
• #2 Measuring agility: a good idea? 
• #3 Measuring agility: what pitfalls to avoid (1) 
• #4 Measuring agility: what pitfalls to avoid (2) 
• #5 Measuring agility: what to measure (1) 
• #6 Measuring agility: what to measure (2) 
• #7 Measuring agility: the final word 

Paul is annoyed

Paul* is a project manager at a software company called Scholesoft*. Recently, Scholesoft has been trying to change the way they operate. They have been trained in agile practices and approaches, and apply a number of things in their daily work.

The goal for Scholesoft is to deliver new features more regularly, produce quality software, and find the right balance between user satisfaction and a sustainable work pace for everyone.

Before switching to an agile mode of operation, Paul had dashboards with indicators that he followed: number of man-days consumed, budget monitoring, respect for each feature of the estimate made upstream, number of anomalies by status and criticality... This allowed him to have a certain vision of his projects and to make decisions based on these indicators.

But Paul is annoyed.

At the last steering committee meeting, Alex*, the big boss, indicated that the battery of indicators followed at the level of each project should be changed to include "agility indicators". For Paul, agility is still new. Frankly, is there really a need to evolve the current indicators, which provide interesting information? What indicators should we follow? But first of all, what do "agility indicators" mean?

Measuring agility requires knowing what agility is

In order to measure agility, it would be interesting to look at the definition of agility. This is the least we can do to know what we are going to measure. And on this first point, not everyone agrees. For some, agility is about working methods. For others, it is a philosophy. But how do you measure work methods? How do you measure a philosophy?

You may have already heard of the Manifesto for Agile Software Developmentwhich lays the foundation for the agile philosophy, with four core values and twelve principles that are equally important. This document, written by seventeen signatories in 2001, is a cornerstone for the agile movement. However, it remains very theoretical: for example, we value people and interactions more than processes and tools.

When I deliver training, the first step is to try to make the learners understand what agility is, and why being agile is important. Being agile, because what matters is the final result: did we manage to deliver more consistently? More often? A better quality deliverable?

These are the kinds of things that will define whether the agile initiative we've been trying to launch has really paid off. It's not so much what we put in place to get there: Scrum? Kanban? Extreme Programming practices?

Is being agile a characteristic?

Being agile, finally, can be seen as a characteristic of an organization, a team, a system, an individual. Not long ago, when I was coaching a company in Montpellier, I tried to define it this way:

A characteristic A characteristic of an individual, team or organization that is able to adapt to changes in its environment through :

• The most regular and frequent delivery of value possible, according to the evolving expectations of its users and its ecosystem;
• An exemplary mindset that promotes collaboration, autonomy and self-organization;
• The constant search for quality and improvement in its activities and interactions.

You will tell me that this definition is probably not perfect. But there is not ONE perfect definition of agility. In any case, this definition does not seem to me to be separate from the values and principles of the agile movement.

A characteristic, then? Like being tall or short, friendly or unpleasant, brown or red-haired? It can be heard. And as for these, it is important to understand that agility is not a "flag" with two states (agile / not agile).

Boolean isAgile = true;

I sometimes hear people, teams, organizations say that they are "full Agile": what does that mean? Who can claim, today, to have reached the maximum level of agility? Who knows, by the way, what the maximum level of agility is? Does it even mean anything?

The process of becoming more agile is an incremental one. The starting point is our current state. The arrival point is... to be defined. Like when preparing a marathon: there are those who want to run it in two hours, others in four hours, others who just want to finish it.

To do this, we need to understand what agility is: we have talked about it. Then, for each of the axes we have discussed (value delivery, quality research...), we can try to make measurements independently and learn from them. This could be a way to "measure agility".

What is our delivery frequency? What is our return rate? Our user satisfaction score? This is the starting point. What would we consider an acceptable result on each of these indicators? That can be the end point.

Our indicators then provide us with what they are supposed to: an understanding of the present, which allows us to make decisions for the future.

Measuring agility: next episode

Is measuring agility a good idea, or is it incompatible with agile values and principles? What pitfalls should be avoided? Which indicators should be measured? Stay tuned for future articles on the subject.

*Paul, Alex and Scholesoft are purely fictitious.