Coaching Agile : L’intelligence du Burn-down Chart

Coach Agile, Scrum Master, vous le savez, le Burn Down Chart permet de suivre la progression d’une équipe sur son objectif de sprint en mesurant le travail effectué et le travail restant avec le temps disponible.
Cependant, au delà d’un outil de suivi, le burn down permet aussi de détecter des dysfonctionnements au sein d’une équipe ou même au sein d’une organisation.

Nous allons voir au travers de cet article comment le burn down chart permet d’identifier des problèmes de différents types :

• Systémiques (goulot d’étranglement dû à une attente ne dépendant pas de l’équipe par exemple)
• Organisationnel
• D’équipe (dans la maîtrise de SCRUM)

Ci-dessus vous pouvez visualiser le burn-down idéal, connu de tous. Nous allons dans la suite de cet article visualiser quatre différents patterns de burn down révélant des dysfonctionnements d’équipe SCRUM ou d’organisation. Commençons par le premier anti-pattern: La validation des US tardive ou non dépendante de l’équipe.

1. Une validation tardive ou hors équipe

Avant de lire la suite de cet article, il est à noter que le burn down chart est construit et reflète l’avancement de l’équipe en cohérence avec la définition du terminé (définition of done) déterminée par celle-ci.

Ce bad pattern peut être exprimé de la façon suivante : La validation des US est soit faite trop tardivement par le product owner qui les accepte ou les rejette au dernier moment dans le sprint soit, encore pire, la validation des US ne dépend pas de l’équipe mais d’une entité extérieure.

Comme vu ensemble, ce burn down met en lumière différents problèmes. Essayons d’identifier leurs sources :

• Le manque de disponibilité du Product Owner : Le product Owner n’est pas disponible pour l’équipe. Il n’est pas présent pour clarifier, donner du sens et valider les développements effectués.
  Ce manque de disponibilité créé un goulot d’étranglement sur les tests et tire donc indirectement à la baisse la vélocité de l’équipe et ainsi la valeur apportée au produit.
• La fluidité de communication : Nous rencontrons souvent ce problème avec un proxy product owner qui, par définition, travaille à distance de l’équipe. Dans ce genre de cas, il faut penser à affiner sa définition du terminé.

Les conséquences

Comme vu ci-dessus, il y a de lourds impacts. Entre autres :

• Baisse de la vélocité
• Mise en péril de l’incrément produit
• Perte de la notion d’engagement car cet engagement ne dépend pas directement de l’équipe
• Débordements et reliquat à traiter (ou pas suivant la re-priorisation du product owner) sur le prochain sprint ce qui induit un surplus de complexité.

Ainsi, si ce n’est pas un épiphénomène, c’est-à-dire d’identifier et de traiter les causes du problème.

Que faire dans ce cas ?

Plusieurs pistes sont possibles et à envisager pour rectifier ces problèmes d’équipes

• L’enrichissement du burn-down : Créer par exemple deux courbes :
  • Suivre comme dans l’actuel le « Done = développé + testé »
  • Suivre le « développé » uniquement
  • Ceci aura pour effet de visualiser le goulot d’étranglement et de préserver la notion d’engagement de l’équipe
•  Repenser la stratégie de tests si le PO n’est pas disponible

Et vous, avez-vous déjà rencontré ce SCRUM BAD PATTERN ? Avez-vous identifié des solutions ?

Voyons maintenant d’autres problèmes révélés par les burn down :

2. Une progression lente ou un sur-engagement

Plusieurs comportements peuvent être à l’origine de ce genre de Burn Down :

• L’équipe trop ambitieuse : L’objectif du sprint est trop ambitieux et l’équipe réalise seulement pendant le sprint qu’elle n’atteindra pas l’objectif du sprint. (A noter : S’il est acceptable de viser haut et d’échouer, il ne faut pas que cela devienne une habitude ou un modèle régulier, car cela influence négativement la confiance de l’organisation dans l’équipe.)
• L’équipe soumise : L’équipe n’est pas assez responsabilisée et n’ose pas affronter le product owner en donnant une vision réaliste mais peut etre perçue comme douloureuse de sa capacité de production sur un sprint. Cette fausse promesse peut aussi mener à un manque de confiance de l’organisation vers l’équipe.
• La variance de l’équipe : Les équipiers tombent malade ou partent, partent en vacances sans que cela n’ai été identifié lors de lancement du sprint.
• La changement de priorité de dernière minute : L’équipe doit résoudre un problème critique – souvent un bug – qui laisse moins de capacité à accomplir l’objectif de sprint. Selon la fréquence de ces perturbations, il faut peut être laisser du mou sur l’engagement de l’équipe.
• Les adhérences et dépendances : L’équipe fait face à des dépendances en dehors de sa sphère d’influence non prévisibles lors de la planification du sprint. (Note: Un dysfonctionnement systémique classique.)

3. L’augmentation du périmètre

La plupart du temps, on observe ce burn down lorsque la préparation du sprint n’a pas été bien menée :

• Un mauvais découpage : L’équipe n’est pas parvenue à découper les stories et n’a donc pas identifiée que l’effort de création d’un incrément de produit (du sprint) allait être plus important que prévu. Si cela se produit régulièrement, cela signifie que l’équipe a accepté des user stories non comprises ou avec trop d’incertitude, ce qui montre de sérieux dysfonctionnement.
• D’importantes variations sur le périmètre : Souvent dues à un manque de priorisation ou à un manque de mou ne permettant pas de gérer les urgences.

Que faire ?

Par exemple :
Instaurer une séance de backlog refinement à mi sprint afin d’arriver en lancement de sprint avec des user stories mâtures.
Se laisser un peu de mou sur le sprint (ne pas s’engager aux limites de sa capacité de production) à combler avec des actions d’améliorations au besoin afin d’avoir de la bande passante pour gérer les urgences.

Le sous-engagement

Attention, ce burn down n’est un anti-pattern SCRUM que si celui-ci se produit régulièrement. On ne va pas critiquer une équipe qui travaille parfois mieux que prévu !

Néanmoins, si ce burn down est une habitude dans vos équipes :

• L’équipe trop prudente : L’équipe a probablement surestimé l’effort lors de son estimation. Cette mauvaise estimation peut découler de user story non maitrisée, ou d’une angoisse de l’équipe dans un contexte trop strict ou l’on accepte pas “l’échec”.
• Pas de visibilité sur les actions techniques : L’équipe garde de la capacité de production pour traiter des tâches techniques (refacto / gestion de la dette technique) sans donner de la visibilité sur ces actions.

En conclusion

1. C’est un bonne idée d’analyser parfois le burn down pourquoi pas après un stand-up ou lors d’une rétrospective en essayant d’identifier les problèmes systémiques.
2. On peut donner encore plus de transparence et de visibilité en couplant le burn down chart avec d’autres indicateurs, par exemple le cycle time, le lead time, etc…
3. Il est bénéfique de mettre à jour le burn down lors des mêlées quotidiennes sans que cela soit systématiquement au Scrum master de le faire. N’hésitez pas à créer un tâche tournante au sein de l’équipe.

Et vous ? Utilisez vous les burn down pour vous poser de bonnes questions ? Dites-le nous dans l’espace dédié aux commentaires !