Engineering manager : les métriques que je surveille

C’est le quatrième article de ma série sur ce que le rôle d’engineering manager m’a appris. Comme pour les épisodes précédents, ce qui suit n’est ni une méthode ni une vérité générale : c’est un retour d’expérience personnel, structuré autour des citations et des principes que des personnes qui ont compté dans mon parcours m’ont transmis, et de ce qu’ils m’apportent au quotidien.

Le premier épisode portait sur le rôle et la posture d’engineering manager, le deuxième sur le 1:1 et le suivi individuel, le troisième sur donner des objectifs et de la vision. Vous pouvez retrouver tous les articles de la série sur la page du tag engineering-management.

Ce billet-ci se concentre sur les métriques que je surveille en tant qu’engineering manager : lesquelles j’utilise vraiment au quotidien, celles dont je me méfie, et la façon dont je les lis : pas comme des absolus, mais comme des tendances.

N’hésitez pas à me proposer les métriques que vous suivez avec vos équipes : je serais curieux de découvrir comment chacun aborde le sujet. Mes réseaux sont accessibles depuis ce blog.

Pourquoi je surveille des métriques

Avant de parler des chiffres eux-mêmes, une précision sur la posture. Une métrique, ce n’est pas un tableau de bord qu’on brandit pour justifier une décision. C’est avant tout un instrument de calibrage : elle m’aide à comprendre où en est l’équipe, à détecter tôt un problème, et à savoir si mes choix de découpage ou de priorisation produisent l’effet attendu.

J’avais déjà posé cette idée dans l’article précédent à propos du lead time : ce n’est pas un outil de flicage, c’est un instrument de calibrage. La même logique s’applique à toutes les métriques. Dès qu’un chiffre sert à juger une personne plutôt qu’à comprendre une situation, il devient toxique, et je reviendrai sur ce point à la fin.

Ce qui ne veut pas dire grand-chose : la vélocité

« La vélocité individuelle ou même la vélocité de l’équipe, ça veut pas dire grand-chose. » (Florent Dubost, mon manager pendant plusieurs années)

C’est une phrase que je me répète souvent, parce que la vélocité a tout pour plaire : elle se calcule facilement, elle se résume en un chiffre, et elle donne l’impression de mesurer « combien on produit ». Sauf que ça ne mesure en réalité presque rien.

D’abord, comparer la vélocité de deux équipes n’a aucun sens : chaque équipe découpe, estime et compte ses points à sa façon. Ensuite, même au sein d’une même équipe, la vélocité agrège tout ce qui n’est pas comparable : un point n’est pas une valeur livrée. Une équipe peut très bien avoir une vélocité qui augmente pendant que la valeur délivrée, elle, plafonne ou régresse.

La seule question qui m’intéresse, c’est : est-ce qu’on livre, en valeur, ce qu’on avait prévu de livrer ? La vélocité ne répond pas à cette question. C’est pour ça que je m’en méfie.

Et il y a une autre raison, toute pratique : la vélocité est hyper sensible à la disponibilité de l’équipe et aux événements « extérieurs ». Une personne en vacances, un incident, une période d’onboarding, une semaine de conférences : tout ça fait chuter la vélocité sans qu’on ait rien changé à notre façon de travailler. Difficile, dans ces conditions, d’en tirer des analyses directes. À la limite, elle ne raconte que des variations, pas des causes.

Ce que je regarde vraiment : le cycle time

« Le throughput, franchement, pas trop. Le cycle time en médiane et en moyenne, oui, si je regarde. » (moi, en résumant ce que je regarde au quotidien)

Si je devais ne garder qu’une famille de métriques, ce serait le temps. Le lead time (déjà vu) mesure le temps entre l’idée et la livraison. Le cycle time, lui, mesure le temps entre le début du travail sur un sujet et sa mise en production. Deux angles proches, mais le cycle time a l’avantage de commencer là où l’équipe a réellement la main.

Le throughput, c’est-à-dire combien d’éléments on livre par unité de temps, je le regarde très peu. Il raconte un volume brut, sans rien dire de la valeur ni de la difficulté. À l’inverse, je surveille le cycle time, et je le regarde de deux façons complémentaires :

• la médiane, qui me dit ce qui se passe pour le sujet « typique » de l’équipe, sans être perturbée par les extrêmes ;
• la moyenne, qui, elle, est sensible aux valeurs extrêmes : si elle s’envole pendant que la médiane reste stable, c’est le signe qu’il existe des sujets coincés quelque part, qui prennent un temps anormal.

Confronter les deux, c’est un réflexe simple qui en dit long : une médiane basse avec une moyenne haute, c’est la signature d’un backlog où quelques sujets traînent depuis des semaines pendant que le reste avance vite.

Le vrai temps de release : deploy + rollback

« Ok tu déploies en 10 min mais il te faut combien de temps pour rollback ? C’est automatisé ? » (Kenny Dits, mon chef)

Cette question de Kenny m’a marqué, parce qu’elle déplace le vrai sujet. On a tous tendance à juger une livraison sur la rapidité du déploiement : « on déploie en dix minutes ». Sauf que le temps de release ne se limite pas au deploy. Il faut y ajouter tout ce qu’il faut pour revenir en arrière si quelque chose ne va pas : le rollback.

Un déploiement en dix minutes sans rollback automatisé, c’est un déploiement qui peut vous coûter une soirée entière. C’est cette logique qu’il faut intégrer : le vrai temps de release, c’est deploy + rollback. Et un rollback n’est un vrai filet de sécurité que s’il est automatisé, au même titre que le deploy, et pas une procédure manuelle qu’on redécouvre dans l’urgence.

J’en tire une règle simple que j’applique aux créneaux de mise en production : si quelqu’un de l’équipe libère à 18 h 30 et que le temps total (deploy + rollback) est d’une heure, alors il faut s’attendre à pouvoir être occupé jusqu’à 19 h 30. Autrement dit, une release, on la place en connaissant le pire cas, pas le meilleur.

Le deploy frequency et mon rapport au déploiement continu

Des métriques DORA¹, celle que j’exploite principalement, c’est la deploy frequency : la fréquence à laquelle on met en production. C’est la plus parlante pour l’équipe, parce qu’elle raconte directement le rythme de livraison, celui qu’on ressent au quotidien.

Cela dit, je n’applique pas le modèle « déploiement continu à chaque merge sur la branche principale » de façon dogmatique. C’est un très bon objectif dans beaucoup d’équipes, mais ce n’est pas une fin en soi. Ma préférence, et je l’assume, c’est plutôt un déploiement régulier à chaque Mesure (cette unité de temps dont je parlais dans l’article précédent), après une démo aux stakeholders pour valider les développements.

Concrètement : on développe pendant la Mesure, on présente ce qui est prêt aux parties prenantes, et c’est après cette validation qu’on déploie. La fréquence est donc régulière et prévisible, mais elle est pilotée par un moment de validation humaine plutôt que par chaque merge. Ça colle mieux à la façon dont je veux que l’équipe avance : livrer souvent, mais en sachant ce qu’on livre et pourquoi.

Ce choix a aussi un effet d’entraînement sur les parties prenantes. Un déploiement régulier, à un rythme connu, habitue tout le monde au fait que ce rythme existe, et crée une forme de confiance dans le « ça sort à la prochaine Mesure ». Ça prendra quelques mois, mais ce rythme finit par être compris par l’équipe et autour de l’équipe, et surtout, il évite les sempiternelles questions du « quand est-ce que ça sort ? ». On sait, et on le sait ensemble.

Enfin, déployer souvent présente deux avantages que je ne veux pas perdre de vue. D’abord, cela permet de détecter les régressions plus vite : moins il y a d’écart entre ce qu’on livre et la production, plus il est facile de remonter à l’origine d’un problème. Ensuite, cela engage moins à chaque release, tout simplement parce qu’on lance moins de code en production à chaque fois. Le rythme régulier à chaque Mesure n’est donc pas en contradiction avec ces bénéfices : il les garde, tout en introduisant le moment de validation qui me semble indispensable.

Pour fixer ce rythme, une mise en garde : plutôt que de vous donner un objectif non SMART du type « déployer plus souvent », donnez-vous un rythme précis et soutenable, et tenez-vous y. Un rythme qu’on tient sur la durée vaut toujours mieux qu’une ambition qu’on abandonne au bout de deux semaines.

Et quand vous voulez améliorer le temps de déploiement, pensez à toute la chaîne deploy + rollback, pas seulement au geste de déploiement en lui-même. Identifiez l’étape qui prend le plus de temps et attaquez-vous à elle en priorité : c’est là que vous gagnerez le plus. Pour donner un ordre de repère, un temps de deploy + rollback viable, pour moi, c’est moins de trente minutes.

La rétro radar, pour suivre le qualitatif

Les métriques techniques disent beaucoup du rythme et de la stabilité, mais elles sont muettes sur l’essentiel : comment les gens se sentent dans l’équipe. C’est là qu’intervient la rétro radar, le format de rétrospective en radar que Caroline Le Lay, une amie et ancienne collègue, m’a fait découvrir. Je la fais environ tous les six mois, et je la trouve très intéressante pour mesurer l’évolution qualitative et humaine de l’équipe.

Le principe est simple. On définit des axes, chacun représentant une dimension de la vie d’équipe. Chez moi, ils sont dix : collaboration, fun, apprentissages, mission, ownership, process, ressources, rôles, vitesse et valeur. À chaque itération, chaque membre se positionne sur ces axes, et on reporte les résultats sur un radar : plus on est loin du centre, plus la dimension est au vert.

Chaque axe correspond à une question précise sur la santé de l’équipe :

Un détail pratique qui change tout : j’envoie le formulaire à l’avance. Si chacun remplit son positionnement avant la séance, la rétro elle-même ne sert plus à collecter des réponses, mais uniquement à échanger, à prendre des notes sur les résultats, et à définir ensemble des actions. On gagne un temps précieux et on garde la séance pour ce qui compte : la discussion et les décisions, pas la saisie.

L’intérêt n’est pas tant la forme du radar à un instant t que son évolution d’une itération à l’autre. On superpose le radar de la fois précédente et celui du jour : ce qui s’agrandit, ce qui se rétracte, ce qui se dégrade sans qu’on l’ait vu venir. C’est un excellent détecteur précoce : une dimension qui se dégrade discrètement pendant deux itérations mérite qu’on s’y attarde avant que ça ne devienne un problème.

Un squelette d’axes que vous pouvez adapter :

# Rétro radar · Mesure du AAAA-MM-JJ

| Axe            | Position (1 à 5) | Commentaire |
| -------------- | ---------------- | ----------- |
| Collaboration  | …                | …           |
| Fun            | …                | …           |
| Apprentissages | …                | …           |
| Mission        | …                | …           |
| Ownership      | …                | …           |
| Process        | …                | …           |
| Ressources     | …                | …           |
| Rôles          | …                | …           |
| Vitesse        | …                | …           |
| Valeur         | …                | …           |

Comme pour le journal de bord et le brag document vus dans le deuxième article, l’important est de consigner : c’est en superposant les relevés successifs qu’on voit l’évolution, pas en se fiant à la mémoire de « ce qu’on ressentait la dernière fois ».

Regarder les tendances, pas les absolus

Une dernière chose, peut-être la plus importante. Ce que j’évite avec les métriques, c’est de les regarder comme des absolus. Un chiffre isolé ne veut pas dire grand-chose : « notre cycle time est de cinq jours » n’a de sens que comparé à ce qu’il était il y a un mois, ou à ce qu’on s’était fixé.

Je regarde donc surtout les tendances et les évolutions. Est-ce que ça s’améliore, est-ce que ça se dégrade, est-ce que ça stagne ? C’est la pente qui m’intéresse, pas la valeur. Une métrique qui se dégrade légèrement mais dont on connaît la cause est bien moins inquiétante qu’un chiffre stable dont plus personne ne se demande pourquoi il est ce qu’il est.

Et surtout, une métrique ne doit jamais devenir une cible à atteindre à tout prix : sinon elle cesse de mesurer la réalité et commence à la déformer². Le jour où un chiffre devient un jugement sur les personnes plutôt qu’un instrument de compréhension, il faut savoir le ranger. C’est le meilleur garde-fou que je connaisse.

Et la suite ?

Il reste d’autres aspects des métriques que je n’ai pas abordés ici. Si vous voulez que je précise un point ou que j’aborde un thème en particulier, mes réseaux sont accessibles depuis ce blog : écrivez-moi, je serai ravi de vous lire.

Le prochain épisode portera sur le recrutement, l’onboarding et l’offboarding, un sujet que j’ai déjà évoqué en passant dans le deuxième article. Comme toujours, vous pouvez retrouver l’ensemble de la série via le tag engineering-management.