Mesurer l’agilité : qu’est-ce que cela signifie ?

Tous les articles de notre série “Mesurer l’agilité” :

• #1 Mesurer l’agilité : qu’est-ce que cela signifie ?
• #2 Mesurer l’agilité : une bonne idée ? 
• #3 Mesurer l’agilité : quels pièges éviter ? (1) 
• #4 Mesurer l’agilité : quels pièges éviter ? (2) 
• #5 Mesurer l’agilité : que mesurer ? (1) 
• #6 Mesurer l’agilité : que mesurer ? (2) 
• #7 Mesurer l’agilité : le mot de la fin 

Paul est embêté

Paul* est un directeur de projet dans une société qui produit des logiciels, Scholesoft*. Depuis peu, Scholesoft essaie de changer de mode de fonctionnement. Ils ont suivi des formations autour des pratiques et approches agiles, et appliquent un certain nombre de choses dans leur quotidien.

L’objectif, pour Scholesoft, est d’arriver à délivrer plus régulièrement de nouvelles fonctionnalités, produire des logiciels de qualité, et trouver le bon équilibre entre la satisfaction des utilisateurs et un rythme de travail soutenable pour tout le monde.

Avant de passer à un mode de fonctionnement agile, Paul avait des tableaux de bord avec des indicateurs qu’il suivait : nombre de jours hommes consommés, suivi du budget, respect pour chaque fonctionnalité de l’estimation réalisée en amont, nombre d’anomalies par statut et criticité… Cela lui permettait d’avoir une certaine vision sur ses projets et de prendre des décisions en fonction de ces indicateurs.

Mais Paul est embêté.

Lors du dernier comité de pilotage, Alex*, le grand patron, a indiqué qu’il faudrait faire évoluer la batterie d’indicateurs suivie au niveau de chaque projet pour y intégrer des “indicateurs d’agilité”. Pour Paul, l’agilité, c’est encore nouveau. Franchement, y a-t-il vraiment besoin de faire évoluer les indicateurs actuels, qui remontent des informations intéressantes ? Quels indicateurs suivre ? Mais avant toute chose, ça veut dire quoi, des “indicateurs d’agilité” ?

Mesurer l’agilité nécessite de savoir ce qu’est l’agilité

Pour mesurer l’agilité, il serait déjà intéressant de s’intéresser à la définition de l’agilité. C’est la moindre des choses pour savoir ce qu’on va mesurer. Et sur ce premier point, tout le monde n’est déjà pas d’accord. Pour certains, l’agilité, ce sont des méthodes de travail. Pour d’autres, c’est une philosophie. Mais comment mesurer des méthodes de travail ? Comment mesurer une philosophie ?

Vous avez peut-être déjà entendu parler du Manifeste pour le développement agile de logiciels, qui pose les bases de la philosophie agile, avec quatre valeurs fondamentales et douze principes qui le sont tout autant. Cet écrit, rédigé par dix-sept signataires en 2001, fait office de pierre angulaire pour le mouvement agile. Cependant, il reste très théorique : par exemple, nous valorisons les individus et les interactions plus que les processus et les outils.

Lorsque je dispense des formations, la première étape est d’essayer de faire comprendre aux apprenants ce qu’est l’agilité, et pourquoi être agile est important. Être agile, car ce qui compte, c’est bien le résultat final : a-t-on réussi à délivrer plus régulièrement ? Plus souvent ? Un livrable de meilleure qualité ?

C’est ce genre de choses qui définiront si l’initiative agile que nous avons essayé de lancer a réellement porté ses fruits. Ce n’est pas tant ce qu’on a mis en place pour y arriver : du Scrum ? Du Kanban ? Des pratiques Extreme Programming ?

Être agile, une caractéristique ?

Être agile, finalement, on peut le voir comme une caractéristique d’une organisation, d’une équipe, d’un système, d’un individu. Il y a peu, alors que j’accompagnais une entreprise montpelliéraine, j’essayais de le définir de cette façon :

Une caractéristique propre à un individu, une équipe ou une organisation, qui est capable de s’adapter aux changements de son environnement, via :

• La livraison la plus régulière et fréquente possible de valeur, en fonction des attentes évolutives de ses utilisateurs et de son écosystème ;
• Un état d’esprit exemplaire favorisant la collaboration, l’autonomie et l’auto-organisation ;
• La recherche constante de la qualité et de l’amélioration dans ses activités et ses interactions.

Vous me direz que cette définition n’est sans doute pas parfaite. Mais il n’y a pas UNE définition parfaite de l’agilité. Cette définition ne me paraît en tout cas pas décorrélée des valeurs et principes du mouvement agile.

Une caractéristique, donc ? Comme être grand ou petit, être aimable ou désagréable, être brun ou roux ? Cela peut s’entendre. Et comme pour celles-ci, il faut bien comprendre que l’agilité n’est pas un “flag” à deux états (agile / pas agile).

Boolean isAgile = true;

J’entends parfois des personnes, des équipes, des organisations dire qu’elles sont “full Agile” : qu’est-ce que cela peut bien signifier ? Qui peut se targuer, aujourd’hui, d’être arrivé au niveau maximum de l’agilité ? Qui sait, d’ailleurs, ce qu’est le niveau maximum de l’agilité ? Est-ce que cela veut au moins dire quelque chose ?

La démarche vers plus d’agilité est une démarche progressive. Le point de départ est notre état actuel. Le point d’arrivée est… à définir. Comme lorsqu’on prépare un marathon : il y a celles et ceux qui ambitionneront de le courir en deux heures, d’autres en quatre heures, d’autres voudront juste le terminer.

Pour cela, il faut comprendre ce qu’est l’agilité : nous en avons parlé. Puis, pour chacun des axes que nous avons évoqués (livraison de valeur, recherche de la qualité…), nous pouvons essayer de réaliser des mesures de façon indépendante et en tirer des enseignements. Cela pourrait être une façon de “mesurer l’agilité”.

Quelle est notre fréquence de livraison ? Notre taux de retours sur livraisons ? Notre score de satisfaction utilisateur ? C’est le point de départ. Qu’est-ce qui nous paraîtrait un résultat acceptable sur chacun de ces indicateurs ? Cela peut être le point d’arrivée.

Nos indicateurs nous apportent alors ce qu’ils sont censés nous apporter : une compréhension de l’actuel, qui nous permet de prendre des décisions pour l’avenir.

Mesurer l’agilité : la suite au prochain épisode

Mesurer l’agilité, est-ce une bonne idée, ou est-ce antinomique avec les valeurs et principes agiles ? Dans quels pièges ne pas tomber ? Quels indicateurs mesurer ? Restez connectés pour être mis au courant des prochains articles sur le sujet.

*Paul, Alex et Scholesoft sont purement fictifs.