Nous entendons souvent qu’il est totalement impossible d’avoir une vélocité à 0… Et pourtant ce cas bien que rare peut arriver. Bien que la vélocité soit un indicateur bien moins important que l’importance qu’on lui accorde, sur le coup de la vélocité à 0, il permet de mettre le doigt sur un gros dysfonctionnement.
Petit rappel sur la notion de vélocité
Sans rentrer dans le détail car un article explique concrètement cette notion de vélocité, elle représente le nombre de points d’effort « done » en fin de sprint.
Et si votre équipe réalise un scrum proche de ce qui se fait dans 80% des cas, le « Done » représente toutes les items qui répondent à 100% à la Definition of Done. Si un item répond à 95% des critères du Definition of Done, il ne doit pas passer en « Done » et sera alors considéré comme non réalisé ; il n’y aura pas de pourcentage d’avancement pris en compte.
Voici l’un des 12 principes du manifeste agile qui vous rappelle qu’un item est réalisé… ou non réalisé :
Un logiciel opérationnel est la principale mesure d’avancement.
Manifeste Agile
Donc si aucun ticket en fin de sprint ne répond à 100% du Definition of Done, votre vélocité en fin de sprint sera de « 0 » tout simplement.
Nous avions parlé de la vélocité en vidéo sur La Minute Agile, n’hésitez pas à la regarder.
Donc ce n’est pas si impossible d’avoir une vélocité à 0…
En effet, bien que cela n’arrive pas souvent, il est possible de rencontrer ce cas dans certains produits. Nous allons voir quelques exemples que j’ai déjà rencontré dans le passé.
Les serveurs sont down…
En effet, dans les grands groupes, il n’est pas rare que les serveurs soient gérés par des équipes dédiées aux infrastructures. Si votre équipe n’est pas en mesure de livrer le rendu sur un espace de recette, il sera impossible au product owner de tester et valider l’aspect fonctionnel de ce qui a été livré.
Cela est dans le cas (très fréquent) où la Definition of Done contient le critère « validé par le product owner ».
L’équipe peut donc malheureusement se retrouver avec une fin de sprint où aucune user story n’est validé.
Le socle technique plus long que prévu…
Quand vous ne réalisez pas de framing agile surtout dans certains contextes comme l’univers du big data, il n’est pas rare que le socle technique mette plusieurs sprints pour réellement émerger. Parfois cela est aussi du au retard de validation des outils à acheter ou à valider avant mise en place sur les serveurs.
Si les équipes ne peuvent pas développer d’items testables, la vélocité restera à 0. Cela ne signifie évidemment pas que l’équipe ne travaille pas.
La vélocité à 0 n’est pas un drame… Voire parfois le résultat d’un choix judicieux
J’ai déjà vu dans le passé, un produit ayant une vélocité à 0 pendant 4 sprints d’affilés. Les environnements de recette ont mis 2 mois à être fournit à l’ensemble de l’équipe ; cela était du à une longue attente de validation de logiciels spécifiques.
Quand la vélocité est utilisée comme KPI de reporting (à ne jamais faire), cela va créer des tensions et des peurs au niveau du management.
Pourtant mieux vaut avoir une vélocité à 0 que de se presser sur une mauvaise solution rapidement mise en place. Il faut impérativement penser « qualité » pour avoir des produits réellement utilisés.
Et dans ce cas , il était impossible de tester en développement car les outils sur cet environnement ne permettaient pas d’avoir réellement les résultats attendus.
Conclusion la vélocité à 0
En effet, bien que rare, la vélocité à 0 est un cas que l’équipe peut rencontrer lors du développement de son produit. Loin d’être un drame, attention à ne pas tirer la sonnette d’alarme un peu trop vite.
`
Soyez le premier à commenter