Métriques en Agile: les bonnes, les mauvaises et les moches!

Dans son dernier article https://age-of-product.com/agile-metrics-good-bad-ugly, Stefan Wolpers fait le tour de quelques métriques Agiles en exposant ceux qui sont intéressantes au niveau des équipes et au niveau organisationnel, ainsi que ceux qui n’ont pas de valeur!
voici ce qu’il nous apprend!

Mesurer son succès grace aux métriques en Agile peut refléter le progrès de l’équipe vers l’Agilité ou encore le progrès de l’ensemble de l’Organisation vers une Organisation apprenante.

Au niveau de l’équipe, les métriques qualitatives ont généralement un meilleur impact que les métriques quantitatives. Au niveau organisationnel, c’est plutôt l’inverse, les métriques quantitatives sont plus perspicaces!

Les bonnes métriques Agiles

Les métriques nous aident à mieux comprendre la situation courante. De ce fait, Ils nous aident à mieux planifier éventuel prochain changement. Évaluer l’effort de développement sans métrique serait une interprétation biaisée.

Une bonne métrique offre la possibilité d’analyser la cause dans le temps d’un comportement donné. Elle indique alors un changement de pattern.

Trois règles générales pour une bonne métrique agile

• Règle générale 1 : suivre uniquement les métriques qui s’appliquent à l’équipe. Oubliez les métriques qui mesurent les individus.
• Règle générale 2 : Ne pas mesurer les paramètres pour la simple raison qu’ils sont faciles à mesurer. Cette pratique est généralement la conséquence d’utiliser plusieurs outils qui offrent des rapports “out-of-the-box”.
• Règle générale 3 : Évitez les mesures qui sont plus “contextuels” et ne sont pas une tendance. Par exemple, le nombre d’incident pendant un sprint.

Exemple :

Si le sentiment (en moyenne) sur la métrique de la dette technique est en train de diminuer (tranquillement mais continuellement) peut indiquer :

• que l’équipe a probablement commencé à sacrifier la qualité de code pour rencontrer – arbitrairement – des dates cibles, ou
• L’équipe a délibérément bâti des solutions temporaires pour accélérer l’expérimentation.

La dernière interprétation est intéressante. Par contre, la première est un peu inquiétante. Il faut analyser cela avec l’équipe lors d’une rétrospective.

Bonnes métriques qualitatives pour l’équipe

Les tests d’auto-évaluation

Les tests d’auto-évaluation permettent de suivre le progrès vers l’adoption des techniques et processus Agiles.

Il y’a une panoplie de tests sur le net. Celle que je préfère est la check-liste d’Henrik Kniberg. (EN : son explication sur comment utiliser, et ne pas utiliser cette liste : https://www.crisp.se/gratis-material-och-guider/scrum-checklist)

Chaque 4 à 6 Semaines, vous pouvez faciliter une session avec l’équipe durant une rétrospective, vous enregistrez et vous agrégez les résultats. Vous pouvez utiliser un code couleur (Vert, Oranger, Rouge) pour répondre aux questions, selon cette échelle :

• Vert : Cela marche pour l’équipe!
• Orange : Cela marche pour l’équipe, mais on peut s’améliorer encore la dessus.
• Rouge : Soit que cela ne s’applique pas, par exemple, l’équipe n’est pas en train d’utiliser les courbes de burndown, soit la pratique est en train d’échouer.

En enregistrant les codes couleurs sur le temps, on peut observer la tendance (vers le vert ou vers le rouge) et s’adapter au besoin. Le Scrum Master peut aider l’équipe à s’améliorer, et aussi avoir des discussions avec le management s’il y’a une nécessité de formation ou autre.

Les sondages anonymes

En complément à l’autoévaluation, un bon exercice est aussi de rouler un sondage anonyme à la fin de chaque sprint. Le sondage contient quatre questions. Les réponses sont sur une échelle de 1 à 10.

1. Quelle valeur l’équipe a livré le dernier sprint? (1: nous n’avons livré aucune valeur; 10: nous avons livré le maximum de valeur possible)
2. Comment la dette technique s’est développée le dernier sprint? (1: nous avons réécrit toue l’application; 10: Pas de dette technique)
3. Est ce que vous recommandez une opportunité de travail dans cette organisation à un collègue qui adore l’agilité et qui a un état d’esprit Agile? (1: Non, notre relation d’amitié est plus importante que cette organisation; 10: Absolument! Sans hésiter une seconde)
4. Êtes-vous heureux de travailler avec vos collègues? (1: No, Je suis en train de me chercher un autre travail; 10: J’adore mon équipe et cette organisation! On est le meilleurs!)

Cette évaluation prend moins d’une minute à répondre. Les résultats seront évidemment disponibles pour tout le monde. Encore une fois, l’idée est d’observer la tendance sur certains aspects que l’on peut oublier.

Bonnes métriques quantitatives : Le délai de mise en œuvre (Lead Time) et le temps de Cycle (Cycle Time)

L’objectif de toute transformation agile est de permettre à l’organisation de devenir une organisation apprenante afin de gagner un avantage compétitif par rapport à la compétition. Les deux métriques que l’on va voir s’appliquent aussi bien au développement logiciel qu’à d’autres processus de livraison. Elles proviennent en fait de la pensée Lean.

L’organisation aura très probablement à se restructurer pour éliminer l’effet Silo vers une structure multi-disciplinaire, et de permettre aux équipes de s’auto-organiser. Il sera aussi question d’analyser le système lui-même en utilisant ce qu’on appelle la gestion des files d’attentes, afin de trouver les choses qui stagnent et qui bloquent le flot de création de valeur.

Afin d’identifier ces files d’attente dans le processus de livraison actuel, on commence par enregistrer 5 dates :

1. La date à laquelle une idée précédemment validée, par exemple, une user story pour une nouvelle fonctionnalité, devient un item du backlog de produit.
2. La date à laquelle cet item de backlog de produit devient un item de backlog de sprint.
3. La date à laquelle le développement commence sur cet élément de backlog de sprint.
4. La date à laquelle l’item de sprint rencontre la «Définition de Terminé» de l’équipe.
5. La date à laquelle l’item de sprint est livré aux clients.

Le délai de mise en oeuvre inclut tout le temps écoulé entre la première et la cinquième date. Il inclut toutes les étapes préalables avant que l’équipe commence le travail proprement dit sur l’item. Tandis-que le temps de cycle est le temps dans lequel on effectue le travail. C’est le temps écoulé entre la troisième et la quatrième date.

L’objectif est de réduire le délai de mise en oeuvre et le temps de cycle, afin d’augmenter la capacité de l’organisation de livrer de la valeur. L’objectif est atteint en éliminant les dépendances et les transferts entre les équipes au sein du processus de livraison du produit.

Plusieurs pratiques sont installés dans ce contexte, comme :

• créer des équipes multi-disciplinaires
• créer des équipes fonctionnelles ou de domaine au lieu d’équipes responsables d’un composant.
• Promouvoir une perspective holistique, globale du produit et une pensée systémique parmi tous les membres de l’équipe.

Mauvaises métriques agiles

La controversée volatile, mais populaire.. Vélocité de l’équipe! Seule une équipe expérimentée peut utiliser, pour elle-même, cette mesure.

D’autres facteurs peuvent rentrer dans la catégorie “Mauvais”, surtout lorsqu’on commence à comparer des équipes. Pour plus de métriques pour ce sujet, consultez mon article Métriques pour une équipe Scrum Hyperproductive

Et la métrique moche?

Bon.. La plus moche selon moi est “le nombre de story points par développeur dans un intervalle de temps”. Elle équivaut les métriques du genre : nombre de lignes de code, ou nombre d’heures du reporting dans l’approche traditionnelle de gestion de projets.