Ca fait 25 ans que je fais du logiciel, que ce soit en tant que développeur, chef de projet, formateur, coach, manager.
Si les compétences techniques sont clefs pour réussir, les compétences relationnelles sont tout aussi importantes : il y a bien longtemps que fabriquer du logiciel est devenu une activité collective pour la plupart des entreprises.
Récemment, je me suis posé la question de formaliser comment je trouvais pertinent d’évaluer la performance des équipes, et voici les métriques qui me semblent importantes.
Le lead time
Je prends cette notion de lead time au sens du temps nécessaire pour passer de l’idée de quelque chose, le plus souvent une feature, à sa mise en production.
Ou pour être plus précis : le temps écoulé entre le moment où tu dis “on va faire ça” et sa mise en production réelle dans les mains des utilisateurs.
Par exemple : si le lundi l’équipe décide de faire 3 features, que la première est livrée le mardi, la seconde le mercredi et la dernière le jeudi, ça fait un lead time de (1+2+3) / 3 = 2.
Le concept est très simple, sa mesure un peu moins. Mais si tu as un board numérique avec une gestion d’états, ça devrait pouvoir se faire assez bien.
Le lead time est une mesure de la capacité de l’équipe à s’adapter à son environnement, à avoir une boucle de feedback rapide avec ses utilisateurs. C’est pour moi une mesure essentielle.
Elle condense beaucoup de choses sur l’équipe : sa capacité à découper finement les objectifs business, sa maîtrise de sa stack technique, sa capacité à communiquer et répartir le travail, sa capacité à prioriser correctement les tâches pour aller vers un objectif précis, sa capacité à gérer la dette technique.
Bref, si je ne devais en garder qu’une, ce serait celle-là.
La fréquence des déploiements
C’est une corollaire de la métrique précédente. Pour avoir un lead time court, il faut pouvoir livrer facilement et livrer fréquemment.
Si tu livres tous les 3 mois, c’est évident que tu auras moins de feedback que si c’est tous les jours.
Cette métrique vient dire des choses sur la capacité de l’équipe à fluidifier ses processus, sa maîtrise de sa chaîne de production de valeur, sa capacité à se synchroniser pour livrer souvent sans se bloquer mutuellement.
Nombre de bugs critiques
C’est pour moi une mesure indirecte de la qualité logicielle livrée. Indirecte parce qu’elle ne dit pas tout de l’état interne du code, mais visible par l’utilisateur. On peut mesurer les bugs par livraison ou en garder une trace et gérer la pile de bugs.
Spoiler : si tu dois gérer ta liste de bugs, c’est que tu as un gros problème de qualité.
Une variante de cette mesure est la quantité de régressions : quand tu livres quelque chose en cassant autre chose, c’est une régression.
Ces mesures viennent dire des choses sur la maîtrise technique de l’équipe sur sa stack et son code.
Capacité à résorber la dette technique
La dette est inexorable dans un projet. Ce que j’appelle dette, c’est du code en dessous de son standard de qualité. Du code non testé, du code dupliqué, du code ‘vite fait mal fait mais qui fait le taff’, du code qui tiendra pas la charge et qu’on optimisera le moment venu.
Le problème n’est pas de contracter de la dette, c’est de ne pas la rembourser. Car lorsque les intérêts deviennent trop lourds, cela consomme trop d’énergie et nuit à la santé de l’équipe.
Par exemple, est-ce que l’équipe supprime régulièrement le code mort qui encombre le répo ?
J’ai toujours mesuré cette métrique au feeling. Si je devais la quantifier, je le ferais sur une échelle de maturité :
- la dette technique s’accumule sans qu’elle soit traitée.
- une partie de la dette est résorbée, mais elle continue de s’accumuler.
- il y a encore de la dette générée, mais l’équipe en résorbe plus qu’elle n’en génère.
- l’équipe génère très peu de dette et de manière conscience. Elle en résorbe en continue.
- La dette n’est pas adressée.
- La dette est résorbée lors d’ateliers ou chantiers spécifiques
- Le code est ajouté proprement et ne génère plus de non qualité
- Le système est rénové au fil des développements : chaque zone touchée est rénovée au fil de l’eau
J’hésite encore entre ces deux métriques.
Les soft skills
En ce qui concerne les soft skills, ces métriques me semblent de bons indicateurs de la performance d’une équipe :
- Fréquence de rétrospective
- Sécurité psychologique
- Autonomie dans les décisions
- Capacité à résoudre des problèmes
L’occasion de les détailler bientôt 😘
Juste des chiffres
Attention : les métriques ne sont que des mesures. Il est important de réaliser deux choses :
- constater une non performance n’aide pas à régler les problèmes, mais uniquement permet de les identifier et d’en parler pour essayer de s’améliorer.
- les mesures ont toutes des biais induits qui peuvent fausser l’analyse. Ce ne sont que des chiffres à prendre avec recul.
Une question de contexte
Dernier point à retenir : la performance d’une équipe ne peut s’évaluer hors de son contexte.
Le sujet n’est pas de « mettre une note », mais d’utiliser ces métriques comme un moyen d’identifier les zones d’amélioration possible.
Si ces sujets t’intéressent et tu veux en parler, viens échanger sur linkedin : https://www.linkedin.com/in/benoitgantaume/