Gestion & Stratégie. Pourquoi la vélocité d'une équipe agile finit par chuter

Le diagnostic est tentant, rapide, et généralement trop paresseux pour être utile.

La vélocité n’est pas un compteur de motivation branché sur le clavier de l’équipe. C’est une mesure de capacité observée dans un contexte donné. Quand elle chute, elle raconte rarement une simple baisse d’effort. Elle signale plutôt que le système de production s’est grippé quelque part: dette technique qui remonte à la surface, tickets mal préparés, dépendances oubliées, équipe recomposée, décisions qui arrivent trop tard. Bref, tout ce que le tableau de suivi préfère souvent garder sous le tapis.

Et c’est précisément là que commence le vrai sujet: comprendre les raisons d’une perte de vélocité Scrum sans transformer un indicateur de planification en outil de surveillance.

La vélocité Scrum mesure-t-elle vraiment la productivité?

Commençons par le début, parce que même dans les équipes expérimentées, le calcul de la vélocité agile finit parfois par devenir une sorte de rituel automatique. On additionne les points, on compare avec le sprint précédent, puis quelqu’un demande pourquoi la courbe descend. Et, dans la foulée, on cherche un responsable.

La vélocité correspond à la somme des points attribués aux éléments réellement terminés pendant un sprint. Réellement terminés signifie que les éléments respectent la définition de fini de l’équipe. Un ticket à moitié développé, une fonctionnalité en attente de validation ou un correctif encore coincé dans une branche ne compte pas. Même s’il ne manque que cinq minutes de travail — les cinq minutes les plus longues de l’histoire des projets web, évidemment.

Cette règle paraît simple, mais elle change complètement la lecture de l’indicateur. La vélocité ne mesure pas:

• le nombre d’heures passées devant l’écran;
• la quantité de lignes de code produites;
• le nombre de tickets ouverts ou déplacés;
• la performance individuelle d’un développeur;
• la valeur métier livrée à elle seule.

Elle mesure une capacité de livraison exprimée dans l’unité de référence choisie par l’équipe: les story points. Ces points servent à représenter une complexité relative, avec une part d’incertitude et d’effort. Ils ne sont pas des heures déguisées et ne constituent surtout pas une monnaie universelle de comparaison entre équipes.

Une équipe qui livre 30 points n’est pas automatiquement plus performante qu’une autre qui en livre 18. Les deux équipes peuvent utiliser des échelles différentes, travailler sur des architectures différentes, avoir des niveaux d’autonomie différents ou gérer des produits qui n’ont rien à voir. Comparer leurs vélocités revient à comparer deux thermomètres placés dans deux pièces différentes, puis à conclure que l’un des thermomètres travaille mieux que l’autre. On sent déjà le parfum du mauvais indicateur managérial.

Une vélocité qui baisse ne dit pas d’abord que les développeurs travaillent moins. Elle dit que l’équipe termine moins de travail estimé dans les conditions du sprint.

La bonne question n’est donc pas: quelle équipe produit le plus de points? C’est plutôt: qu’est-ce qui a changé dans notre capacité à terminer du travail de qualité?

Pour une équipe nouvellement constituée, une moyenne indicative de 5 à 10 story points par personne sur un sprint de deux semaines peut donner un premier repère. Rien de plus. Ce chiffre ne constitue ni une cible, ni une norme, ni une promesse à faire graver dans le contrat de l’équipe. La vélocité devient utile quand elle se stabilise dans un contexte relativement constant et qu’elle aide à prévoir ce qui peut raisonnablement entrer dans les prochains sprints.

Pourquoi la dette technique fait-elle chuter la vélocité sans prévenir?

La dette technique est rarement spectaculaire au départ. Elle se glisse dans les interstices: une classe qu’on ne refactore pas cette fois-ci, une couverture de tests que l’on remet au prochain sprint, une intégration bricolée pour tenir une date, une règle métier dupliquée à trois endroits. Chaque décision semble locale. Puis le projet grandit, les développeurs changent, les demandes s’empilent et l’ancien raccourci devient une autoroute cabossée.

Au début, l’équipe continue à livrer. C’est ce qui rend la dette technique si dangereuse: elle ne bloque pas immédiatement. Elle rend simplement chaque changement un peu plus lent, un peu plus risqué et beaucoup moins prévisible.

Une évolution qui devrait toucher un seul module déclenche alors une exploration de l’architecture. Un test échoue sans lien évident avec la fonctionnalité en cours. Une migration de données se révèle indispensable. Une règle existe dans le code, dans la documentation et dans la tête d’une personne qui est justement en congé. Sous le capot, le ticket n’est plus un ticket. C’est une expédition.

La baisse de vélocité apparaît souvent quand cette complexité cachée devient impossible à absorber dans le sprint. Les éléments sélectionnés ont été estimés comme s’ils étaient isolés, alors qu’ils dépendent d’un système fragilisé. L’équipe démarre avec une impression de clarté, puis découvre progressivement le vrai périmètre.

La dette technique agit de plusieurs manières:

1. Elle augmente le temps de compréhension.

Avant d’écrire une ligne, il faut retrouver le fonctionnement réel du système. La documentation ne suffit pas toujours, surtout dans les projets anciens où le comportement du logiciel est devenu la documentation de fait.

2. Elle multiplie les régressions.

Une modification apparemment limitée casse une autre partie du produit. Le temps prévu pour développer se transforme en temps de correction, de diagnostic et de vérification.

3. Elle rend les estimations moins fiables.

Les développeurs ne manquent pas nécessairement de compétence. Ils disposent simplement de moins d’informations au moment de l’estimation, parce que la complexité est enfouie dans l’architecture.

4. Elle réduit la marge de manœuvre du sprint.

Le moindre imprévu devient critique. Dans un code sain, une découverte coûte parfois quelques heures. Dans un code saturé de compromis, elle peut remettre en cause le découpage entier.

5. Elle dégrade la définition de fini.

Si les tests, la documentation technique ou les contrôles de qualité sont régulièrement repoussés, les tickets restent ouverts plus longtemps et la vélocité observée diminue mécaniquement.

Il serait pourtant simpliste d’attribuer toute baisse de vélocité à la dette technique. Son impact exact varie fortement selon l’architecture, le niveau de couplage, la qualité des tests et la nature du produit. Il n’existe pas de pourcentage universel de vélocité perdu à cause de la dette. Les projets ne paient pas tous le même intérêt, et certains ont manifestement souscrit à un crédit à taux variable.

Le bon diagnostic consiste à regarder les travaux qui n’étaient pas prévus dans les estimations initiales: investigations, corrections de régression, remise en état d’un composant, opérations manuelles, reprise de données. Si ces activités reviennent sprint après sprint, la vélocité ne baisse pas parce que l’équipe est moins productive. Elle baisse parce qu’une partie croissante de sa capacité sert à maintenir le passé.

Les dépendances cachées bloquent-elles le sprint avant même son démarrage?

Une équipe peut avoir un backlog bien rempli, des développeurs disponibles et une planification parfaitement huilée. Il suffit pourtant d’une dépendance non résolue pour transformer un sprint en exercice de patience.

La dépendance peut être technique: une API qui n’est pas prête, un environnement indisponible, une migration qui doit être exécutée avant le développement, un accès manquant à un service tiers. Elle peut aussi être organisationnelle: une validation juridique, une décision produit, une intervention d’une autre équipe ou une information que personne n’a encore obtenue.

Le problème n’est pas uniquement le temps d’attente. C’est l’effet de cascade. Un ticket bloqué ne reste pas toujours sagement à sa place. Il déplace les développeurs vers un autre sujet, fragmente l’attention, crée du travail en cours et augmente le nombre de reprises de contexte. À la fin du sprint, plusieurs éléments sont entamés, mais peu sont terminés. Or seuls les éléments terminés alimentent la vélocité.

Ce point explique une partie des baisses soudaines. Une équipe peut conserver exactement les mêmes personnes et les mêmes compétences, tout en livrant beaucoup moins de points parce que les conditions d’exécution ont changé.

Un suivi utile ne se contente pas de compter les tickets bloqués. Il cherche à savoir:

• à quel moment la dépendance a été découverte;
• si elle était visible pendant l’affinage du backlog;
• qui devait prendre la décision ou fournir la ressource;
• combien de temps le travail est resté interrompu;
• si l’équipe a pu poursuivre avec un découpage alternatif;
• si le ticket a été remis dans le sprint alors que son blocage persistait.

Une dépendance découverte pendant le sprint est parfois inévitable. Une dépendance découverte après plusieurs jours de développement révèle souvent un problème de préparation. Quant à la dépendance connue mais volontairement ignorée, elle relève moins de l’imprévu que de la stratégie de planning optimiste. C’est une nuance qui fait toute la différence quand on veut améliorer la vélocité Scrum sans simplement demander à tout le monde d’aller plus vite.

Dette technique ou dépendance: comment distinguer les deux?

Dans la réalité, les deux problèmes se renforcent. Une architecture difficile à modifier crée davantage de dépendances. Des dépendances mal gérées poussent à multiplier les contournements. Le projet entre alors dans une boucle peu glamour: on ajoute une rustine pour tenir le sprint, puis on explique quelques mois plus tard que le refactoring est devenu trop risqué.

Que change un mauvais affinage du backlog?

Le backlog refinement — ou affinage du backlog, pour celles et ceux qui aiment quand les mots ont une chance d’être compris du premier coup — n’est pas une réunion de pré-planification où l’on relit mécaniquement des titres de tickets. C’est le moment où l’équipe transforme une intention produit en travail suffisamment clair pour être discuté, découpé et estimé.

Quand cet affinage est bâclé, les problèmes apparaissent généralement au pire moment: pendant le sprint.

Un ticket peut sembler limpide du point de vue métier tout en étant techniquement incomplet. La demande dit ce que l’utilisateur doit obtenir, mais pas quelles données sont concernées, quelles règles existent déjà, quelles limites s’appliquent ni comment vérifier que le résultat est correct. L’équipe estime alors une formulation, puis découvre une réalité beaucoup plus large.

Un backlog mal affiné contient souvent plusieurs catégories de brouillard:

• des critères d’acceptation trop vagues;
• des règles métier implicites;
• des données ou interfaces non identifiées;
• des dépendances absentes de la description;
• des tâches trop volumineuses pour un seul sprint;
• des décisions produit encore ouvertes;
• des contraintes techniques découvertes uniquement au démarrage.

Dans ce contexte, l’estimation devient une négociation avec l’inconnu. Les développeurs peuvent sous-estimer parce qu’ils ne voient pas encore les obstacles, ou surestimer pour se protéger contre les mauvaises surprises. Les deux réactions sont compréhensibles. Aucune ne produit une vélocité très lisible.

L’affinage n’a pas besoin de devenir une cérémonie interminable. Selon la complexité du produit et du backlog, une équipe peut y consacrer habituellement entre une et quatre heures par sprint. La durée n’est pas le sujet principal. La qualité des conversations l’est.

On doit en sortir avec des éléments suffisamment petits, compréhensibles et testables. Pas avec une collection de tickets qui ont simplement été déplacés dans une colonne intitulée « prêts ». Un statut ne rend pas une tâche prête, pas plus qu’un nouveau nom de dossier ne transforme un vieux composant en architecture moderne. La communauté a déjà beaucoup donné à ce genre de fiction.

Le rôle du chef de projet technique, du responsable produit et des développeurs est ici complémentaire. Le produit clarifie le résultat attendu. La technique expose les risques, les dépendances et les options de conception. L’équipe vérifie qu’elle peut réellement prendre en charge le travail. Si l’un de ces regards manque, le ticket peut être acceptable sur le papier et impraticable dans le sprint.

Un backlog rempli n’est pas un backlog préparé. La vélocité souffre moins du manque de tickets que du manque de clarté.

Une équipe recomposée peut-elle perdre de la vélocité sans perdre de compétence?

Oui. Et c’est l’un des points les plus souvent oubliés dans les tableaux de suivi.

La vélocité dépend de la capacité collective, pas d’une addition abstraite de profils disponibles. L’arrivée d’un nouveau développeur peut, à moyen terme, renforcer l’équipe. À court terme, elle demande du temps d’intégration, de la transmission et de la revue. Le départ d’une personne expérimentée peut retirer une connaissance critique du produit, même si son poste est rapidement remplacé.

Le turnover modifie aussi les repères d’estimation. Une équipe qui avait construit une compréhension commune des story points peut perdre cette cohérence quand plusieurs membres partent ou arrivent. Les mêmes valeurs ne représentent plus exactement la même perception de la complexité. Ce n’est pas une erreur de calcul: c’est un changement de contexte.

La composition de l’équipe influence la vélocité à travers plusieurs mécanismes:

• La connaissance du domaine. Comprendre les règles métier permet d’éviter des explorations et des allers-retours.
• La connaissance du code. Une personne familière avec les zones sensibles identifie plus vite les impacts d’une modification.
• L’autonomie. Une équipe nouvellement formée sollicite davantage les responsables techniques et les experts externes.
• La coordination. Plus les rôles et les habitudes changent, plus il faut investir dans les échanges et les décisions communes.
• La cohérence des estimations. Les points restent une mesure relative, liée à une équipe qui partage ses références.

Il faut donc résister à une lecture purement arithmétique. Ajouter une personne ne garantit pas une hausse immédiate de la vélocité. Retirer une personne ne signifie pas non plus que les autres doivent compenser automatiquement. Le développement logiciel n’est pas une chaîne de montage à laquelle on branche un poste supplémentaire pour obtenir davantage de pièces à la minute. Le code a cette fâcheuse manie de dépendre du contexte.

La baisse devient préoccupante quand elle s’accompagne d’une perte d’autonomie, d’un allongement des revues, d’une multiplication des demandes d’aide ou d’un retour fréquent vers les mêmes experts. Dans ce cas, l’indicateur reflète probablement une phase de transition. Il faut alors ajuster les prévisions plutôt que maintenir artificiellement les engagements précédents.

Faut-il suivre une moyenne de vélocité sur 90 jours?

Une seule valeur de sprint raconte très peu de choses. Une maladie passagère, une absence, un incident de production ou une livraison externe peuvent modifier le résultat sans révéler une tendance structurelle. La tentation est pourtant forte de réagir à chaque variation. La courbe descend d’un sprint: alerte générale. Elle remonte au suivant: tout va mieux. Les tableaux de bord adorent ce petit théâtre.

Pour analyser une tendance, on peut observer les trois à cinq derniers sprints afin de calculer une moyenne plus représentative. Une moyenne mobile sur 90 jours apporte une lecture plus lissée, particulièrement utile lorsque la cadence est régulière et que l’équipe travaille sur un produit suivi dans le temps.

Mais une moyenne ne doit jamais remplacer l’analyse. Elle atténue les variations; elle ne les explique pas. Une vélocité stable peut cacher une dette technique croissante si l’équipe compense en travaillant sur des éléments de moins en moins ambitieux. Une vélocité en baisse peut être parfaitement saine si l’équipe a consacré un sprint à réduire un risque architectural ou à remettre à niveau ses tests.

Pour lire correctement la tendance, on peut croiser la vélocité avec quelques signaux qualitatifs et opérationnels:

1. Le nombre d’éléments terminés.

Une baisse des points avec un nombre stable de tickets peut traduire un changement dans la taille moyenne des éléments. Ce n’est pas le même problème qu’une accumulation de travaux inachevés.

2. Le travail reporté.

Les éléments qui passent d’un sprint à l’autre montrent souvent un problème de découpage, de dépendance ou de définition de fini.

3. La part d’imprévu.

Incidents, demandes urgentes, corrections de régression et support technique consomment une capacité qui n’apparaît pas toujours dans le plan initial.

4. Les blocages.

Leur durée et leur fréquence donnent une information plus exploitable qu’un simple total de points.

5. La qualité livrée.

Une vélocité élevée obtenue avec davantage de défauts, de retours ou de travail à reprendre n’est pas une amélioration. C’est une dette qui change de colonne.

6. La stabilité de l’équipe.

Un changement de composition rend les comparaisons historiques moins pertinentes pendant une période d’adaptation.

7. La nature des tickets.

Une série de tâches de maintenance, d’investigation ou de migration ne se lit pas comme une série de fonctionnalités homogènes.

La période de 90 jours est donc un outil de tendance, pas une boule de cristal. Elle devient intéressante lorsque l’on peut mettre en regard les changements intervenus dans l’équipe, l’architecture, le produit et l’organisation du backlog.

Comment agir après le diagnostic?

Une fois la cause identifiée, l’action doit rester proportionnée. Si la vélocité baisse à cause d’un ticket mal découpé, il n’est pas nécessaire de lancer un grand programme de transformation agile. Si la dette technique bloque régulièrement les évolutions, en revanche, traiter uniquement les symptômes dans le backlog produit ne suffira pas.

Quelques décisions ont un effet direct sur la lisibilité de la capacité:

• réserver explicitement une place au traitement de la dette technique;
• découper les éléments trop larges avant la planification;
• faire émerger les dépendances pendant l’affinage;
• revoir la définition de fini si elle ne correspond plus à la réalité;
• documenter les décisions qui évitent de refaire les mêmes investigations;
• adapter les engagements quand la composition de l’équipe change;
• analyser les éléments reportés plutôt que de les effacer du tableau;
• utiliser la vélocité pour prévoir, jamais pour classer les personnes.

Le point décisif est de ne pas corriger l’indicateur à la place du système. Modifier les estimations pour faire remonter la courbe, augmenter la pression ou demander à l’équipe de reprendre davantage de tickets ne rétablit pas la capacité réelle. Cela fabrique seulement une vélocité plus flatteuse — et beaucoup moins honnête.

Alors, que dit vraiment une perte de vélocité Scrum?

Elle dit que le rapport entre le travail prévu et le travail terminé s’est dégradé dans le contexte observé. C’est déjà une information utile. Mais elle ne fournit pas, à elle seule, la cause du problème.

La perte de vélocité Scrum peut venir d’une dette technique qui ralentit chaque modification, d’une dépendance découverte trop tard, d’un backlog insuffisamment affiné ou d’une équipe dont la composition vient de changer. Elle peut aussi résulter de plusieurs facteurs qui se renforcent mutuellement. Dans un projet web en croissance, c’est même le scénario le plus courant: un peu de legacy, un peu de flou produit, quelques validations externes et une équipe qui apprend encore à travailler ensemble. Le quotidien d’une équipe PHP, en somme. La fameuse modernisation continue, celle qui n’a jamais droit à une bande-annonce.

Le rôle du responsable technique n’est pas de défendre une courbe idéale. Il consiste à rendre visibles les contraintes qui influencent la livraison et à créer les conditions d’une capacité plus prévisible. Celui du produit n’est pas de remplir chaque sprint jusqu’au dernier point disponible, mais de clarifier les priorités et les résultats attendus. Celui de l’équipe est de fournir une estimation honnête, de signaler les risques et de terminer un travail conforme à la définition de fini.

La vélocité est précieuse quand elle reste un outil de dialogue. Elle perd toute sa valeur quand elle devient une cible individuelle ou un classement entre équipes. À partir de là, les points gonflent, la qualité se négocie à la baisse et le tableau de bord raconte une histoire que plus personne ne croit vraiment.

La prochaine étape n’est donc pas de faire remonter la vélocité à tout prix. C’est de comprendre ce qui empêche l’équipe de finir son travail, puis de traiter cette cause avec assez de sérieux pour que les chiffres redeviennent un reflet utile du terrain. Le reste, c’est du pilotage sous filtre — et le legacy a déjà suffisamment de maquillage comme ça.