La vélocité à 0… Vraiment impossible ?

velocity chart
velocity chart

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.

`

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 942 Articles
  Paquet Judicaël (expert en transformation et AI) Mes activités en France et en Suisse : - ingénieur prompt - coach AI - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile, prompt AI, Intelligence artificielle. [Me contacter]

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.