Ce qui n’est pas mesuré ne peut être amélioré

Comment les principes agiles peuvent-ils aider à cadrer et à mesurer le succès ou l’échec, tout en en tirant des leçons ?

La mesure, principe dévié et pourtant essentiel

Les indicateurs souvent utilisés au sein d’une équipe agile deviennent inutiles au moment même où ceux-ci sont utilisés à des fins de contrôle de la performance humaine :

• La vélocité doit être constante ? Elle le sera. Les éléments du backlog seront alors évalués à la hausse ou à la baisse pour répondre à l’attente de la hiérarchie
  • La vélocité doit augmenter tous les trimestres ? Elle augmentera. Une même fonctionnalité estimée à “3” d’effort en sprint 1, sera estimée à “5” en sprint 10 le trimestre suivant, toujours pour répondre à l’attente de la hiérarchie
  • Pas de dette technique ? Elle sera invisible, toujours pour répondre à l’attente de la hiérarchie, comme je l’expliquais il y a quelques semaines
  • Le nombre de fonctionnalités livrées doit être constant ? Il le sera, toujours pour répondre à l’attente de la hiérarchie, grâce peut-être à la shadow-velocité (voir mon guide à ce sujet)

Les indicateurs sont pourtant essentiels pour l’équipe et doivent donc être utilisés uniquement dans un but d'auto-évaluation.

Et la mesure de l’impact, alors ?

Les mesures d’auto-évaluation de l’équipe n’indiquent pas si la fonctionnalité réalisée est utile ou non, aussi bien faite soit-elle.

Pour mesurer l’impact réel d’une fonctionnalité, le Product Owner dispose d’un outil fiable et précis : la sonde.

La sonde est un élément technique rajouté à une fonctionnalité afin de collecter les données sur son utilisation.

Améliorer

Fort de ces données, il y a ensuite des actions à prendre. Si une fonctionnalité n’est pas ou peu utilisée, il y a plusieurs raisons possibles :

• Est-ce vraiment un besoin des utilisateurs ? Si l’idée est née dans la tête d’un marketeur sans une étude préalable, il est possible que l’utilisateur n’ait pas encore l’utilité de la fonctionnalité ou la capacité à l’exploiter

• Les utilisateurs sont-ils au courant ? La fonctionnalité a-t-elle été annoncée et expliquée ?

• **La fonctionnalité est-elle accessible à la bonne cible ? **Si une fonctionnalité est limité à un type d’utilisateur précis, il est important que les indicateurs ne prennent en compte que les comportements de la cible.

• **La fonctionnalité est-elle utilisable ? **Les utilisateurs savent-ils utiliser la fonctionnalité ? Peut-être est-elle trop compliquée ?

L’échec est important et nécessaire. Si nous savons en tirer une leçon, nous pouvons alors agir.

Par exemple nous pouvons mettre en place une action marketing pour annoncer et expliquer la fonctionnalité. Nous pouvons aussi organiser des entretiens utilisateur pour mieux les comprendre.

Il faut aussi savoir tuer une fonctionnalité. Si celle-ci n’apporte rien, elle devient une source inutile de code à maintenir, sans valeur.

S’améliorer

Grâce à ces indicateurs, il est alors non seulement possible d’améliorer le produit, mais aussi de s’améliorer soi-même.

Si la campagne marketing n’a pas fonctionné, il faut pouvoir se remettre en question pour ne pas rater la prochaine.

Si le besoin n’est pas là, comment faire pour éviter de lancer en production un élément inutile ?

Si les sondes n’ont pas permis de comprendre pourquoi la fonctionnalité a eu peu de succès, alors que pouvons-nous en tirer comme conclusion ?

Si vous souhaitez en savoir plus et découvrir d’autres outils pour compléter les sondes, vous pouvez regarder du côté de l’accompagnement du changement (un prochain article y sera consacré)