Récemment, lors de réunions de service, j’ai pu assister à un étonnant spectacle : un manager rendait compte de son activité en projetant les burndown charts des produits sous sa responsabilité.
L’objectif partait d’un principe simple : Partager l’avancement des sprints auprès des autres managers du service. Bon, pas de suspens, c’est une MAUVAISE PRATIQUE. Voyons pourquoi.
Rappel sur le sprint backlog
Le sprint backlog est l’artefact qui appartient et qui est géré par l’équipe de réalisation (Dev Team). Les outils qui en dépendent ne doivent pas sortir de ce périmètre ou en tout cas pas sans autorisation de l’équipe elle-même.
Bien entendu, le sprint backlog doit être transparent et facilement compréhensible. Mais le burndown chart qui en résulte n’est pas un outil d’évaluation de la performance d’une équipe, ni même un outil de reporting.
L’incrément, qui est le fruit du travail du sprint et surtout l’impact qu’il produit une fois livré sont par contre une bonne source d’évaluation de la performance de l’équipe. Et quand je parle de l’équipe c’est toute la Scrum Team (Product Owner, Scrum Master…) pas uniquement les développeurs!
Une source de pression injustifiée sur l’équipe de réalisation
Afficher un burndown au manager c’est afficher une progression sans explications. Pourquoi la courbe augmente-t-elle là et là et encore là ? Il peut y avoir mille explications :
- On apprend tout simplement tout au long d’un sprint : c’est ainsi normal d’avoir des tâches qui se rajoutent et donc une courbe qui ne suit pas forcément la prévision.
- Il peut y avoir des stories qui lèvent des imprévus et donc des tâches supplémentaires.
- Il peut y avoir des problèmes de disponibilité des parties prenantes, du PO… qui retardent l’avancement des tâches.
- Un développeur peut avoir été appelé sur une urgence en dehors du produit.
- …
Tout ceci ne se voit pas et même si le graphique est commenté, le mal est en quelque sorte déjà fait… . Et il est difficile de fournir des explications sans les personnes qui réalisent.
Le risque est de mettre en pâture des chiffres et de fausser les interprétations. Il en résulte un risque de mettre une pression injustifiée sur l’équipe de réalisation alors qu’ils n’ont absolument pas besoin de cela, au contraire! L’effet peut du coup être à l’inverse de celui recherché : une équipe sous stress, qui perd pied, moins motivée et donc… moins performante!
Un niveau de détail pas nécessaire
Il faut bien se poser la question de l’objectif même du reporting. Si c’est pour indiquer un niveau de santé du produit et de sa roadmap un indicateur type feu tricolore n’est-il pas suffisant?
Mais à quoi sert le burndown du coup?
Et bien c’est un outil qui peut être utilisé par la dev team si elle en éprouve le besoin. Pour le Daily Stand Up, il peut permettre d’analyser l’avancement du sprint et d’aider à réagir.
Mais il est sûr qu’il ne remplace en rien la communication entre les équipiers. Un, “daily” quotidien bien mené permet déjà de comprendre le sprint et son avancement, et de faire évoluer le plan en fonction des remontées d’informations de chacun.
Le burndown est juste un outil supplémentaire qui permet d’ajouter une meilleure transparence sur le suivi du plan, mais il reste facultatif.
Gare à la tentation d’en faire un outil pour le management!!!
