Confondre vitesse et précipitation

« L’équipe est à combien de vélocité ? » « Pourquoi vous faites pas monter votre vélocité ? » « Pour qu’on soit dans les temps, je vous demande de multiplier par 2 votre vélocité »

Ces quelques exemples reéls montrent qu’il arrive souvent que la vélocité soit prise par les personnes extérieures aux équipes Scrum, mais parfois aussi par le Product Owner ou le Scrum Master, comme une mesure de productivité d’une équipe.

Déjà. De quoi parle-t-on.

Définissons la vélocité d’une équipe. Il faut savoir qu’il n’est nullement question de vélocité dans le Scrum Guide. C’est un outil qui s’est constitué pour les équipes afin de prévoir (et non pas prédire) la quantité de d’elements qu’une équipe est capable de délivrer pour la prochaine itération. Elle se calcule en faisant la somme des points de complexité des éléments TERMINES durant la précédente itération. On peut lisser cette vélocité en prenant les valeurs des 3 derniers sprints pour obtenir une valeur plus stable. Cette valeur aide l’équipe à définir le contenu d’un sprint « à peu près ». Et c’est suffisant en terme de planification.

Définissons aussi ce que l’on appelle la productivité. Si je m’en réfère à wikipedia : la productivité du travail est définie comme la production (quantité de biens ou de services produits) obtenue pour chaque unité du facteur de production (comprendre ressource) « travail » utilisé. Dans le cas d’une équipe Scrum, la quantité de biens produits pourrait être le nombre de User Stories produites, ou la somme des points de complexité des user stories produites, ou le nombre de ligne de codes pour réaliser les user stories produites et l’unité du facteur de production utilisé pourrait être une équipe Scrum durant une itération.

La productivité d’une équipe serait donc le nombre de User Stories produites durant une itération, ce serait la vélocité de l’équipe ?

Non.

Et n’est pas non plus une mesure de la vitesse à laquelle une équipe ponds des stories.

La vélocité, une mesure quand même ?

On va se le redire tout de suite : oui c’est une mesure, nous l’avons vu plus haut. Non ça ne mesure pas la productivité d’une équipe.

Soyons honnête : on parle de métiers intellectuels, de recherche de solution à des problèmes pas d’une usine d’assemblage de pièces, toutes identiques les unes les autres. Ce n’est pas possible de calculer une productivité qui veuille dire quelquechose. Un logiciel informatique est un ensemble de composants tous différents, du code spécifique à chaque problème à résoudre. Il n’est donc pas possible de dire « aujourd’hui j’ai fait 10 lignes de code, demain je dois faire pareil » ou « ma productivité est de 1 story par semaine ». NON.

La vélocité est un outil de planification, pas une mesure de productivité et de contrôle.

Elle sert à une équipe à jauger de sa capacité à pouvoir terminer des choses dans un temps donné. Point. Cette mesure est dépendante de chaque équipe, de chaque produit et du niveau de collaboration entre tout les membre de l’équipe. A la poubelle les modèles, abaques, comparaison de vélocité entre équipe.

J’aime bien utiliser la comparaison avec tetris : L’objectif d’une itération pourrait correspondre à compléter 4 lignes de tetris. Pour faire ces 4 lignes, l’équipe définit la taille des blocs que lui présente le Product Owner puis les pose 1 à 1. Lorsque l’équipe pense avoir rempli les 4 lignes, l’équipe s’arrête de remplir : objectif atteint !

Lors des premières itérations, l’équipe se rendra compte qu’elle ne sait pas remplir 4 lignes mais 3.5 ou au contraire est capable de remplir 5 lignes. C’est cette mesure de la somme des tailles de blocs que l’équipe est capable de réaliser au cours d’une itération qui corresponds à sa vélocité.

Et elle n’est pas fixe. Parfois on se rate est on fait moins de blocs, parfois l’équipe atteint un niveau de collaboration idéal et en état de Flow, elle remplit 6 ou 7 lignes : c’est une estimation qui permet de se fixer un objectif atteignable et potentiellement reproductible.

Ce qui marche avec des blocs de tetris marche aussi avec le développement logiciel : on cherche à estimer ce que l’on est capable de faire et non à chiffrer dans le détail. Pas la peine de passer 2 jours à chiffrer le moindre traitement : le niveau de précision de ce que l’on sera capable de faire ne sera pas meilleure que de passer 2 heures à définir cette capacité en story points, en taille de t-shirt ou en patates.

La mesure d’avancement doit être un logiciel qui fonctionne, pas le nombre d’heure qu’un dev passe à coder un algo python.

Okay et on fait quoi alors si je veux utiliser la vélocité autrement ?

Déjà se creuser la tête pour identifier ce que l’on souhaite réellement : planifier ? organiser le travail ? Communiquer ? Selon l’objectif visé, la stratégie pour l’atteindre sera différent.

Si on s’en tient à l’usage correct de la vélocité : utilisez cette mesure pour identifier un problème dans l’équipe, pour jauger de la capacité de l’équipe, pour estimer l’atterrissage dans le temps d’une version de logiciel. Et cela ne marche qu’avec une équipe stable et des éléments à réaliser de taille comparable, livrés régulièrement. Il faut donc être TRES prudent lorsque l’on utilise cette mesure.

Et si vous voulez faire autre chose avec la vélocité, de toute évidence ce n’est pas bon signe. Interrogez-vous. Quel est votre intention en manipulant ainsi la vélocité ? N’êtes-vous pas en train, doucement, de glisser vers un bon vieux système command & control ? Et si vous exprimiez votre inquiétude à cette équipe pour travailler ensemble à trouver la meilleure solution ?

Et si vous abandonniez carrément l’usage de la vélocité et testiez l’usage du #noEstimates ?