Comment mesurer la valeur dans une équipe de prod ?
(et pourquoi la mesure de productivité est inutile)
C’est toujours difficile de trouver les bons indicateurs pour suivre le travail des équipes de développement produit et tech. Si il existe beaucoup d’indicateurs qui permettent de mesurer le travail réalisé par une équipe (la productivité, le flux de travaux, la qualité, les performance …), il reste toujours difficile de trouver un indicateur fiable et pertinent pour mesurer l’impact concret des équipes tech sur le “business” final et sur la valeur.
La lecture du livre “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations “ est passionnante et traite un bon nombre de problématiques sur les équipes produits, avec une analyse fine et une approche “objective” (aussi bien techniques, culturelles et organisationnelles) . Si vous n’êtes pas convaincu, vous pouvez aussi lire la review de M. Flower :)
My Foreword to Accelerate
C’est d’ailleurs le sujet de la toute première partie de ce livre : quels sont les indicateurs pour mesurer l’efficacité d’une équipe produit.
C’est quoi la valeur dans une équipe de prod ?
Alors que la réalisation d’une application fait de plus en plus appel à des équipes produits mixtes et pluri-disciplinaires (devs front / back / ops / UX / UI / PM / datas analyst..) il est nécessaire de trouver un sens opérationnel à la “valeur” produite. La valeur qui est produite doit-être globale et partagée par tous et par tous les métiers, et qui est un sens pour le business.
Dans les équipes de delivery produit, on parle souvent de valeur d’un point de vue utilisateur. La valeur est détenue par l’utilisation et l’utilisateur final : plus une fonctionnalité développée répond aux besoins des utilisateurs plus elle a de valeur.
Par extension, dans les process lean et agile, la valeur de ce qui a été produit est liée à la capacité à livrer rapidement, fréquemment afin de récupérer du feedback au plus vite et de livrer la meilleure réponse à ses utilisateurs .
Pourquoi les métriques classiques ne suffisent pas.
Il existe beaucoup de métriques pour mesurer la production et la réalisation d’une équipe produit.
Pour les auteurs de “Accelerate”, d’une façon générale, beaucoup des métriques utilisées souffrent des maux suivants :
- Elles sont basées sur des indicateurs de production (output), d’efficacité/productivité et non sur des indicateurs reflétant la valeur produite (outcomes).
C’est notamment une des dérives que l’on constate parfois avec la mesure de la vélocité par exemple, très répandue avec les méthodes agiles et scrum. L’interprétation de la vélocité (qui est au départ une estimation et un prévisionnel) est souvent déviée pour mesurer la productivité. Je recommande la lecture de cet article ( de 2007 ! ) de Claude Aubry à ce sujet.
- Elle sont parfois trop dépendantes du contexte et des changements.
La mesure de la vélocité est là aussi un bon exemple. Dés qu’il y a des changements dans l’équipe (départ ou nouvelle arrivée d’un collègue, un changement aléa dans la prod…) toutes les prévisions et estimations peuvent changer (et c’est tant mieux). Mais du coup, quel est l’impact sur la valeur produite ? - Elles sont centrées sur le travail individuel et non sur le travail d’équipe. Elles peuvent aussi parfois être orientées métiers (équipes développement, équipe Ops …) et ne sont pas globales, ne mesurent pas le travail fourni à l’échelle de l’équipe produit dans son ensemble (UX/UI , Devs, Ops …).
On pourra citer en exemple le cas des métriques qui mesurent la qualité du code développé ou les performances / rapidité d’exécution d’une application..
Attention, toutes ces métriques ne sont pas inutiles mais elle ne sont pas suffisantes et pertinentes pour mesurer la valeur de ce qui a été produit, et pour mesurer l’efficacité d’une équipe de prod…Il paraît nécessaire de trouver de nouveaux indicateurs !
Mesurer la performance des livraisons
Les auteurs de “Accelerate” ont exposé un nouveau groupe de métriques pour permettre de mesurer la performance d’une équipe : “Software delivery performance”.
Leur différentes analyses et études montrent que les 4 indicateurs suivants peuvent aider à monitorer la production de valeur :
Le lead-time
Le lead-time est l’indicateur clé des process lean, il mesure le temps entre le début de la réalisation d’une story et sa livraison auprès des utilisateurs.
Plus le lead-time est court, plus une feature sera livrée vite, plus vite les utilisateurs seront satisfaits, plus vite l’équipe a des feedbacks.
Plus le lead-time est long, plus la durée entre l’expression du besoin utilisateur et la livraison de la feature sera étendue. Le calcul du lead-time prends en compte l’intervention de tout les métiers qui interviennent dans la conception, la réalisation et la livraison finale.
La fréquence des livraisons
C’est aussi une mesure utilisée dans le paradigme lean via la taille des lots (batch-size).
La mesure de la taille des lots à produire (batch-size) impacte directement le temps pour produire et livrer une feature (lead-time). Plus on arrive à découper les tâches en petits lots, plus on améliore le lead-time, plus on gagne du temps pour livrer aux utilisateurs et récupérer des feedbacks.
Dans le cadre du développement logiciel mesurer la taille des lots à produire est complexe, et très variable du contexte (des équipes qui chiffrent, qui découpent par exemple). C’est là que la métrique sur la fréquence des livraisons peut-être intéressante : plus les livraisons sont fréquentes plus le travail à réaliser a été découpé en lots.
Fiabilité : taux d’erreurs et temps de rollback
Pour produire de la valeur, il faut produire de la qualité.
Un manque de qualité dans la production se paye un jour ou l’autre sur la valeur produite.
Produire un logiciel avec des problèmes de qualité a un impact direct sur les utilisateurs: insatisfaction des utilisateurs, problèmes dans la qualité de service (interruptions de service, par exemple). Mais il y a des conséquences sur l’organisation et un coût de maintenance important pour les équipes. Une partie de l’équipe va se concentrer sur la correction des bugs et ne se concentrera donc plus sur la production de valeur et l’ajout nouvelles features.
Ce coût est d’autant plus élevée si les problèmes de qualité interviennent à posteriori, après une livraison : On passe toujours un temps super long à régler des bugs et à corriger des problèmes après une mise en prod plutôt qu’avant…il y a une perte de temps naturelle.
Deux indicateurs sont intéressants pour mesurer la fiabilité :
- Temps de rollback / remise en état du système (Mean time to restore)
- Pourcentage de livraisons qui ont demandé une intervention “Change Fail percentage”. Ex: rollbacker sur l’ancienne version, livrer un fix dans l’urgence…
Voilà une remise en perspective de quelques indicateurs qui nous rappelle que la valeur d’une équipe produit n’est pas forcément dans sa productivité ni dans sa capacité de production mais sa capacité à livrer régulièrement de la qualité.
