Quand la vélocité ment : la dure leçon d'une équipe hybride
Une équipe produit avec qui j'ai travaillé — appelons-la l'équipe Atlas — a passé la première moitié de 2021 répartie sur trois fuseaux horaires, la moitié à domicile et l'autre en rotation dans un bureau dégarni. Comme beaucoup de groupes cette année-là, elle composait encore avec les ruptures d'approvisionnement, les arrêts maladie et le brassage général de la reprise pandémique. Son Scrum Master suivait fièrement un chiffre avant tout : la vélocité. Elle était passée de 28 à 41 points par Sprint en quatre mois, et la direction adorait le graphique. Le hic, c'est que presque rien n'était réellement livré.
La vélocité est un outil de planification utile. C'est aussi l'une des mesures de Scrum avec lesquelles il est le plus facile de se mentir. L'histoire de l'équipe Atlas mérite d'être racontée parce que ses erreurs étaient banales, pas exotiques — et le remède n'a exigé aucun nouvel outil, seulement de l'honnêteté.
Comment le chiffre s'est éloigné de la réalité
En y regardant de près, trois choses gonflaient le décompte sans rien apporter au client.
Les estimations ont enflé. Sous la pression de « montrer des progrès », l'équipe s'est mise à coter plus haut des tâches semblables. Une tâche qui valait 3 en mars valait 5 en juin. Le graphique montait; le travail ne changeait pas.
Des points étaient réclamés pour du travail inachevé. Des éléments « pratiquement terminés » étaient comptés en fin de Sprint, puis rouverts discrètement la semaine suivante. La vélocité empruntait sur l'avenir.
La définition de « terminé » s'était érodée. Les testeurs étant débordés par les horaires hybrides, « terminé » en est venu à signifier code fusionné, et non testé et livrable. L'incrément n'était pas réellement utilisable.
Rien de tout cela n'était malhonnête dans l'intention. C'était une équipe qui essayait de paraître en santé tout en coulant à pic. Mais la vélocité avait cessé de décrire la valeur livrée pour décrire l'optimisme de l'équipe.
Réinjecter de l'honnêteté
Le Guide Scrum est clair : l'incrément doit satisfaire la définition de « terminé » pour être livrable, et seul le travail terminé compte. Nous sommes partis de là. L'équipe a rétabli une définition stricte — testé, intégré et démontrable — et convenu que tout ce qui n'y répondait pas était reporté avec un crédit nul. La vélocité est tombée à 22 au Sprint suivant. La direction a sursauté. Nous avons tenu bon.
La vélocité sert à la prévision de l'équipe elle-même, jamais de cible imposée ni de comparaison entre équipes.
Estimez la taille relative, puis ne touchez plus à l'échelle; la rebaser en cours de route détruit le signal.
Ne comptez que ce qui satisfait la définition de « terminé » à la revue de Sprint — pas de crédit partiel, pas de reconnaissances de dette.
Observez la tendance sur plusieurs Sprints, jamais un chiffre isolé; une semaine bruyante ne dit rien.
En cinq Sprints, le chiffre honnête s'est stabilisé autour de 26 et, surtout, la revue de Sprint a enfin présenté un logiciel fonctionnel que le Product Owner pouvait livrer. Les prévisions de l'équipe sont redevenues fiables, ce qui comptait bien plus pour les parties prenantes qu'un graphique flatteur. Le travail hybride avait rendu la dérive facile à cacher; la transparence en a été le seul remède durable.
La leçon est simple. La vélocité ne mesure rien en soi — elle n'a de sens que couplée à une définition de « terminé » que l'on respecte vraiment. Dès qu'un indicateur devient un objectif, les gens optimisent l'indicateur plutôt que le résultat. Un conseiller ou un coach peut aider, mais l'essentiel, c'est que l'équipe veuille la vérité plus que la belle courbe.
Si vos indicateurs de livraison racontent une histoire qui ne colle pas à ce que vous livrez, le service-conseil de XNM en réalisation de programmes et de projets peut vous aider à reconstruire des mesures auxquelles vos parties prenantes pourront se fier.