Comment évaluer la performance d’une équipe logicielle

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 parle surtout de la partie 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 problème d’ordre supérieur.

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. En fait elle n’est simplement pas adressée. L’équipe n’en n’est d’ailleurs peut-être pas consciente. A ce stade, ce n’est pas vraiment de la dette, mais de la complexité accidentelle.
une partie de la dette est résorbée, lors d’ateliers ou de chantiers spécifiques le plus souvent, 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. Le code est ajouté proprement et ne génère plus de non qualité
l’équipe génère très peu de dette et de manière conscience. Elle en résorbe en continue. Le système est rénové au fur et à mesure des développements : chaque zone touchée est rénovée au fil de l’eau

Fréquence de rétrospective

Une rétrospective ne produit pas de feature. C’est un temps d’introspection et d’amélioration de l’équipe. L’artefact d’une rétrospective, c’est l’équipe elle-même.
Et en plus, cela demande souvent de l’énergie après le temps commun d’échange. Du coup, c’est souvent un rituel qui saute dès que l’équipe est sous pression.
C’est déjà un bon indicateur s’il y a des rétros régulières : Ce n’est pas toujours bienvenu de rendre les problèmes visibles 😱
Du coup cet indicateur en dit autant sur l’équipe elle-même que sur son contexte.

Sécurité psychologique

Une étude menée par Google, connue sous le nom de « Projet Aristote » a fait pas mal de bruit à sa sortie car elle a mis en évidence que la sécurité psychologique était le facteur le plus déterminant pour la performance des équipes.
La plupart des recherches sur la performance mettaient traditionnellement l’accent sur les compétences individuelles ou les caractéristiques démographiques (intelligence, expertise, expérience). Google a choisi de se concentrer sur ce qui rend les équipes dans leur ensemble performantes, en examinant les interactions et les comportements collectifs.

La sécurité psychologique (le sentiment de pouvoir prendre des risques sans peur de représailles ou d’humiliation) a été identifiée comme le facteur le plus important de performance. Ce concept, bien qu’introduit par la psychologue Amy Edmondson en 1999, n’avait pas encore reçu autant d’attention dans un contexte technologique et organisationnel.

Cette recherche a analysé 180 équipes au sein de l’entreprise et a identifié cinq dynamiques clés influençant leur efficacité :

Sécurité psychologique : Les membres de l’équipe se sentent en confiance pour prendre des risques sans craindre de répercussions négatives.
Fiabilité : Chacun respecte ses engagements et réalise un travail de qualité dans les délais impartis.
Clarté des rôles et des objectifs : Les fonctions, les objectifs et les attentes sont clairement définis.
Sens du travail : Chaque membre trouve une signification personnelle dans son travail.
Impact : Les membres perçoivent que leur travail contribue à des objectifs plus larges et a un impact significatif.

Autonomie dans les décisions

L’autonomie des équipes est une clef essentielle de performance selon moi. Pour qu’elle arrive à l’autonomie, cela signifie qu’elle a acquis les compétences pour l’être, que son périmètre d’action est clairement défini et qu’elle connait les limites des ses prérogatives. C’est tout un travail pour en arriver là, et le résultat dépend beaucoup de l’action du manager.

J’ai défini 4 niveaux de maturité sur cet axe :

L’équipe est en posture d’attente. Elle ne propose rien ni de prends d’initiative
Les membres proposent des actions mais doivent demander l’approbation systématiquement
les membres de l’équipe commencent à prendre des initiatives sur leur champ d’action directe sans demander l’approbation au préalable.
L’équipe est capable de gérer les dépendances externes à l’équipe et devient force de proposition sur ces points.

Capacité à résoudre des problèmes

Savoir identifier les problèmes lors de rétrospectives constructives, c’est très bien. Identifier et comprendre les bloquages techniques est essentiel. Encore faut-il savoir régler les problèmes.

Et ce n’est pas si évident.

Là encore j’ai défini 4 niveaux de maturité :

L’équipe adresse les problèmes au fil de l’eau en appliquant les solutions sans prendre le temps d’une réflexion posée et partagée entre les membres de l’équipe.
L’équipe prend le temps de réfléchir aux dépendances et à l’impact de ce qu’elle est en train de faire. Elle documente ces réflexions de manière ponctuelle.
L’équipe document systématique ce qu’elle fait : le contexte, le problème initial, la solution proposée et l’impact espéré.
L’équipe partage ces documents entre ses membres et avec d’autres équipes pour s’enrichir mutuellement. Elle analyse à postériori l’impact réel et mesure l’écart avec l’attendu.

Juste des chiffres

Attention : les métriques ne sont que des mesures. Il est important de réaliser plusieurs 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.
plus ne veut pas forcément dire mieux : si l’équipe tourne bien avec 1 rétrospective par mois, c’est bien comme ça. Si une mise en production par semaine suffit, ça peut être très bien. La bonne question est plutôt de savoir si la métrique correspond aux besoins du business et son champ de contraintes.

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/