Scrum Velocity – n’est pas une question du temps, mais de la distance

Aujourd’hui, mon article est une réflexion sur mon entraînement physique quand j’étais dans l’armée et la façon dont nous calculons Velocity dans Scrum. La vitesse dans Scrum n’est pas une question du temps, mais de la distance. J’espère que vous ne vous sentez pas ennuyé à le lire …

En 1984, alors que j’étais encore cadet sur le cours d’officiel de l’armée, l’un des jours les plus attendus a été l’examen de capacité physique.

Cet examen a classé les cadets en fonction des résultats de trois tests : course, exercices abdominaux et pompes.

Tous ces tests ont été chronométrés (time-boxed),ce qui signifie, avec un temps fixe. La course avait une durée de 12 minutes et les exercices abdominaux et les pompes une durée de 01 minute chaque.

Pendant cette période, nous avons dû effectuer autant de répétitions que possible et courir aussi loin que possible.

Mais ce n’était pas suffisant pour faire un exercice de toute façon; il fallait le faire correctement, suivant des mouvements bien définis, sinon il ne compterait pas pour le résultat final. En d’autres termes, il devait se conformer à certaines conditions pour être considéré comme fait (done).

Les pompes et les essais abdominaux ont été relativement faciles car ils n’ont duré qu’une minute.

Le plus grand défi a été la course de 12 minutes. Pendant ce temps, nous avions une distance minimale à compléter, mais il n’avait pas une distance maximale. C’est le test qui a vraiment défini le classement des cadets.

Les meilleurs élèves ont toujours réussi à compléter plus de 3000 m au cours de ces 12 minutes, mais une grande majorité a terminé entre 2 400 et 2 700 mètres.

Quelqu’un qui a fait moins de 2.400 mètres aurait à répéter le test un autre jour, sinon ils auraient une note insuffisante.

Au fil du temps, nous finissons par améliorer (improve) notre force physique et adapter (adapt) nos entraînements en plus de bien connaître le parcour de la course.

Cela nous a permis de courir une plus grande distance à chaque test physique.

Je me suis rendu compte qu’il ne servait à rien de commencer à courir très vite au début et d’avoir ensuite aucune résistance pour terminer la course.

Il était important que j’aie pu maintenir un rythme constant (constant pace) pendant la majeure partie de la course et à la fin si j’étais en bon état, alors je sprintais plus vite pour atteindre des marques qui me mettront dans un meilleur endroit.

35 ans plus tard

À cette époque, je n’imaginais pas ce qu’était Scrum, mais j’avais déjà pratiqué certains principes sans même le savoir.

Scrum est comme un test d’éducation physique.

• Le Product Backlog était la liste des tests à effectuer dans un sprint d’une journée
• Chaque événement a une durée fixe (time-boxed) qui ne peut pas être dépassée.
• L’exécution des activités devait suivre une stratégie de rythme constant pour obtenir les meilleures performances tout au long de la course.
• Nous devrions rester concentrés sur nos exercices pour faire de notre mieux.
• Le résultat final dépendait beaucoup plus du rythme et de la qualité des exercices que du temps nécessaire pour les faire.
• Plus nous nous entraînions, plus la distance parcourue était grande, ce qui générait plus de points et d’efficacité.

Vitesse = efficacité

Dans Scrum, Velocity est le nombre de fonctionnalités que nous sommes en mesure de livrer à la fin de chaque sprint. Ces fonctionnalités doivent respecter tous les critères TERMINÉSpour être prises en compte. Si une fonctionnalité n’est pas considérée TERMINÉE, elle n’est pas livrée.

De la même façon qu’il était dans mon test physique. Si un exercice n’a pas été effectué selon certaines règles de performance, il n’a pas été considéré comme TERMINÉ.

Dans scrum ainsi que dans mon test physique, la vitesse doit être une preuve d’efficacité, c’est-à-dire de faire quelque chose de bien fait dans les plus brefs délais.

Lors de mon test de course, il était inutile d’essayer de terminer 3000 m en 15 minutes. Le temps maximum que j’avais était de 12 minutes pour parcourir la plus longue distance possible. Le résultat de ma course dépendait beaucoup plus de la distance parcourue que du temps de course.

Même si je savais que certains collègues pourraient courir plus vite que moi, je devais obéir à mon rythme pour terminer la course de la meilleure façon possible. Au fond, ce n’était pas une compétition, mais une question d’évolution personnelle.

Dirigez votre équipe comme une compétition individuelle

Un bon Scrum Master sait motiver son équipe pour améliorer sa vitesse.

Une équipe scrum doit développer de nouvelles compétences et se renforcer afin que lors du prochain sprint, elle soit plus performante que la précédente.

Il est nécessaire de faire une bonne analyse à la fin de chaque sprint et de trouver des moyens d’améliorer les performances pour augmenter la distance parcourue.

Il ne sert à rien de comparer la vitesse d’une équipe avec une autre équipe, car ce sont des personnes différentes, avec des connaissances différentes et des performances différentes.

La chose la plus importante est que chaque équipe s’améliore individuellement après chaque livraison. La Velocity est spécifique pour chaque équipe.

Certaines équipes pourront parcourir 3 000 mètres en 12 minutes, d’autres ne parcourront que 2 400 mètres. C’est correct.

Au fil du temps, vous saurez ce que chaque équipe peut faire dans un sprint.