Trop de métriques ne servent à rien

Pendant (trop) longtemps, mon boulot a consisté à mettre à jour des tableaux de bord à chaque fin de semaine. Il y en avait plein plein, avec beaucoup de formules, des dizaines de pages à chaque fois... je me demandais franchement qui ça pouvait intéresser.

Bien plus tard, j'ai pu constater qu'elles n'intéressaient effectivement pas grand monde.

Seules quelques métriques étaient lues par mon supérieur : si le nombre d'incidents montait ou descendait, leur temps de résolution et le rapport de satisfaction des utilisateurs. Eventuellement si certains incidents avaient été résolus "pour de bon" plutôt que par une solution de contournement.

Les tableaux étaient mis à disposition sur l'intranet, peut-être que d'autres gens les lisaient? Nous les avons présenté lors d'une réunion de la DSI. Quelques personnes ont été étonnées des chiffres. Les métriques leurs ont donné une vue d'ensemble , dont elles n'avaient pas conscience dans leur quotidien. Elles leur ont donné un peu de recul, par exemple sur un incident X qui apparaissait beaucoup plus souvent qu'ils ne le pensaient. Cela peut pousser l'équipe à prendre le temps de traiter le problème de fond.

Néanmoins, globalement, les équipes ont semblé peu intéressées par tous ces chiffres. On ne voyait plus rien. Nous avons alors réduit le nombre d'indicateurs, pour qu'ils ne soient plus noyés dans d'autres statistiques. Qu'il y en ait peu, mais qu'ils soient utiles.

L'argent dans les métriques

C'était l'autre problème : ils étaient jolis mais plutôt inutiles.. Les tableaux de bord étaient finalement juste des chiffres "comme ça". Personne ne se basait dessus pour piloter quoique ce soit, c'était illustratif et plat. Nous nous sommes alors inspirés du principe des Balanced Scorecard (BSC) pour trouver d'autres indicateurs avec du sens.

Balanced Scorecard

En cherchant à rentrer dans ce moule, nous avons réussi à refaire la même erreur, même si c'était dans une moindre mesure : nous avons crées d'autres métriques inutiles, comme celle de l'apprentissage. C'était conforme au BSC alors on était contents.... Il y en a quand même eu une qui a bien fonctionné : la perspective financière. Le fait de ramener une non résolution de tickets à de l'argent a donné plus d'importance à l'incident. Cela se traduit par la durée du ticket mais aussi la récurrence du même ticket. Comme il est plus rapide de donner une solution de contournement, les causes profondes d'un problème n'étaient pas forcément investiguées. En transformant cela en argent, on se dit : "ah oui quand même....". Nous sommes alors plus enclins à geler les developpements quelques jours pour trouver la cause.

Ramener (oralement) quelque chose à de l'argent a un effet assez sympathique (c'est un chef de projet qui m'a appris ça, merci à lui !) et c'est assez simple à faire : le développement de telle fonctionnalité a duré 2 semaines avec 4 développeurs. A fortiori, cela permet de rappeller au client que rien n'est gratuit, que même la "petite" fonctionnalité glissé entre deux itérations a un coût. En ayant bien conscience de cela, il peut mieux prioriser et repérer ce à quoi il est prêt à renoncer si les choses se passent mal.

Le feedback des utilisateurs

Chaque mois, le même panel d'utilisateurs était sollicité par téléphone pour donner une note à l'application et éventuellement faire des commentaires. C'était indéniablement la métrique la plus intéressante. Des courbes montraient l'évolution sur l'année, par utilisateur, dans la mesure où haque personne n'a pas la même notion de "bonne note".

Les commentaires ouverts nous permet d'enlever tout préjugé implicite, dont nous impregnions nos métriques. Ils nous font découvrir des choses et laisse le micro aux vrais gens.

Les métriques comme preuves

Nous pouvons adorer les métriques, et trop se reposer sur elles, trop les valoriser. En constituant une "preuve de bon boulot", les équipes concentrent leurs efforts sur elles. On se satisfait d'avoir faire le nécessaire pour avoir un bon résultat "métriquement". Pire, on peut faire des mauvais choix pour valoriser la métrique, en faisant l'économie sur les tests afin de maximiser la vélocité notamment. Nous pouvons nous dire : facile, ajoutons aussi des métriques sur les tests. Cette approche de la carotte est néfaste car elle pousse l'équipe à travailler pour la métrique, pas le produit. Par là, elle bride les initiatives.

Du coté de la direction, voir que les métriques vont bien peut laisser croire que tout va bien. Sans nous inciter à récolter d'autres signaux, plus humains. Le fait que le nombre d'incidents baissait pouvait par exemple finalement dire que l'application était tellement bugguée que les utilisateurs appelaient directement le niveau 2 au lieu de passer par le Help Desk (qui enregistrait les tickets). A contrario, le fait qu'ils augmentaient pouvaient être "bon signe" (<=> les problèmes sont de plus en plus visibles). Le fait de communiquer régulièrement avec les utilisateurs limitent les mauvaises interprétations.

Les métriques des projets traditionnels sponsorise les projets agiles

Dans le webcast "The top 5 metrics and Myth", Pete Behrens rappelle les métriques traditionnelles des projets waterfall : si un projet est livré à temps (apparemment jamais) et s'il rentre dans le budget (un projet sur deux). On remarquera au sujet du budget que le changement d'avis et/ou malentendus creuse la facture par le biais des avenants. Ces dépassements sont beaucoup moins fréquents dans les projets agiles. C'est louche.

Est-ce que la production de valeur en patirait? Non, car de toute façon 64% des fonctionnalités des logiciels ne seraient quasiment jamais utilisés. Dans ce cas, on ne produit pas autant mais mieux?

Non plus. On livre mieux ET plus, car les livraisons sont plus fréquentes. Il n'y a pas de gaspillage car tout ce qui est développé est livré au plus tôt. Terminé! les problèmes de fonctionnalité finies à 99% mais à laquelle l'utilisateur ne peut pas goûter.

Les métriques de performance sont nuisibles

Pete Behrens recommande la prudence sur les indicateurs de performance, qui servent finalement à récompenser ou à réprimander. Plus il y a d'indicateurs de performances, plus la performance réelle baisse.

20_myth_metrics_drive_performance.jpg

La vélocité par exemple n'est pas pertinente pour mesurer la performance car :

  • les points sont relatifs
  • ils sont incomparables entre plusieurs équipes
  • certaines stories ont plus de valeurs que d'autres

Attention, elle constitue une métrique intéressante, mais pour la prévisibilité (estimer une date de mise en production), par pour la productivité. Je trouve aussi qu'y accorder trop d'importance nous fait parfois faire de mauvais choix.

Comparer le prévu au réalisé est une pratique très répandue. Surtout qu'au début, nous sommes toujours en dessous de l'estimé (ce n'est pas si simple de faire des estimations!).

22_prevu_realise.jpg

Pourtant cet indicateur a des effets pervers si l'on insiste trop dessus. A force de se faire rappeler à l'ordre, l'équipe risque de prendre de prendre de moins en moins de fonctionnalités / de sur-évaluer les tâches / de faire du pessimisme aigu pour être sûrs à 100% de pouvoir respecter l'engagement. Donc ok les choses deviennent prévisibles mais finalement l'équipe est moins productive.

L'indicateur peut être utilisé mais il faut que ce soit constructif : étudier pourquoi les stories n'ont pas été faites et engager des actions. Il doit être employé pour s'améliorer et non pour punir. Pour cette raison, je trouve l'indicateur intéressant en interne mais je ne le communiquerais pas au client, qui aura tendance à le voir uniquement en terme de performance / contre-performance.

Deux idées reçues

Behrens poursuit en évoquant des mythes.

28_agile_metrics_description.jpg

Deux m'ont particulièrement plu :

  1. "Une bonne vélocité est toujours une bonne chose". Effectivement, nous sommes nombreux à être contents quand la vélocité est elevée. Pourtant, elle peut vouloir indiquer que la dette technique ne fait que s'accumuler. Il faut veiller à aussi la mesurer en parallèle pour ne pas transformer l'application en géant aux pieds d'argile. L'auteur recommande donc d'être prudent vis à vis du culte de la nouvelle fonctionnalité.
  1. "Un sprint raté est une mauvaise chose". Behrens parle des sprints comme des entrainements, que c'est normal qu'il y ait des hauts et des bas. Il faut les voir comme des occasions de pratiquer un art, l'art de délivrer des produits de haute qualité. Permettre les erreurs, c'est permettre la croissance et la productivité, car chaque erreur est une opportunité d'apprentissage.

Quelques métriques intéressantes

Leading Answers préconise des métriques globales aux métriques individuelles, afin de valoriser la communication, le partage de connaissances et de tirer les compétences de toutes les équipes vers le haut. On se pousse les uns les autres au lieu de se tirer dans les pattes entre l'exploitation, les designers, les testeurs, les développeurs. Le revers est que comme c'est global, on peut ne pas se sentir particulièrement concerné...

Mike Griffiths recommande aussi de récolter régulièrement une note du sponsor : -1, 0 ou 1. Si nous n'avons pas réussi à le lui demander, c'est -1 car cela veut dire que l'on ne le voit décidément pas souvent ! En principe, le scrum master voit tout le monde individuellement avant chaque rétrospective. Après je me demande si cela vaut la peine de formaliser les états d'ames de l'équipe dans une métrique. Dans la mesure où c'est traité très tot grâce aux rétros, cela ne me parait pas nécessaire.

Behrens privilégie les enquêtes auprès des utilisateurs, sur des critères qualitatifs et quantitatives : le temps de réponse, la qualité des fonctionnalités, le support.

Les Running Tested Features (RTF) qu'il évoque par ailleurs me semble être les moins mauvaises métriques avec l'enquête utilisateurs. Ils constituent le nombre des tests exécutables : unitaires et fonctionnels sur un produit pour une équipe. Ils permettent de voir si l'on devient de plus en plus agiles. Ou si notre produit est meilleur avec le temps ou pas. Leurs avantages :

  • augmentent la confiance de l'équipe et du management
  • motivent l'ecriture de tests
  • incitent à ecrire des tests plus petits

Ici encore, comme toute métrique, elle ne doit pas être idéalisée au point de pousser les équipes à faire des tests qui ne servent à rien ou ne testent rien pour faire du chiffre.

D'autres métriques sont mentionnées, je vous invite à regarder la vidéo si vous souhaitez en savoir plus. Voici deux slides de mise en bouche :

27_agile_metrics.jpg

30_extending_metrics.jpg

Alors pour quoi faire?

Je crois que les métriques ne sont utiles que si elles sont employées dans le but d'apprendre. Quand elles sont remises sur la table lors de rétro par exemple. Les métriques de Sonar vont plus loin en signalant directement ce qu'il vaut mieux faire quand une mauvaise pratique est détectée. Le corollaire est qu'une métrique qui n'est pas régulièrement consultée ne sert à rien. Il vaut donc mieux ne pas trop en avoir.

Elles peuvent aussi permettre de prédire les choses, mais de façon approximative. Il faut bien se donner une marge, ne pas les prendre comme argent comptant. Globalement, il vaut mieux éviter de leur accorder trop d'importance.

Si une métrique est utilisée pour évaluer nos performances, les équipes risquent de faire le nécessaire pour améliorer uniquement la métrique, sans chercher à améliorer le produit globalement.

Quant-à avoir un indicateur pour savoir un clin d'oeil si un projet se porte bien ou non, rien ne vaut la communication à travers des points réguliers. Les enquêtes utilisateurs ont elles aussi beaucoup de valeurs. Nous pouvons ensuite en faire un résumé avec très peu d'états "bien", "moyen", "pas bien" pour l'upper management.

Et vous qu'en pensez-vous? Quelles métriques vous sortent par les yeux? Lesquelles appréciez-vous? Est-ce qu'elles vous motivent? A quoi vous servent-elles?

Liens mentionnés dans le billet : Leading Answers, Vidéo de Behrens

Sources des images : BSC Vidéo de Behrens,