Est-ce un point de non retour sur l’acceptation par les équipes de développement de la méthode. De nombreux retours d’expérience vont dans ce sens où la non adhésion complète des principes remettait en cause le résultat de cette méthode.
Dans un séminaire Agile, Greg Hutchings avait évoqué les patterns/anti patterns de l’agilité, le premier anti pattern étant de ne pas appliquer complètement la méthode, mais par petit bout.
Le post de Claude Aubry remet en cause le burndwon au profit d’un suivi des tâches par état.
Pourquoi remettre en question les bases de Scrum et délaisser le burndown au profit d’un suivi par état. Le suivi par état en plus du burndown, je suis d’accord, mais pas en remplacement.
Scrum est basé (comme beaucoup) sur la notion de charge : estimée, produite, consommée, restante à faire,… en d’autres termes de productivité.
- Xébia rappelle que « Scrum a été conçu pour atteindre une productivité de 5 à 10 fois supérieure… »,
- Une itération en Scrum s’appelle un sprint, ce n’est pas pour rien.
Je préfère l’approche « complément » présentée par Mike Cohn. qui propose des solutions visuelles améliorant la lisibilité du burndwon par adjonction d’information sur la priorité, ou celle présentant le backlog produit avec une Treemap, une présentation surfacique relative aux poids de chaque user story.
Mais dans les deux cas, Mike garde la notion de charge : poids, estimation, reste à faire.
Je sais qu’il est difficile dans notre contexte très dirigé par les contrats au forfait de parler de charge. C’est quand même la base d’une gestion de projet, sans parler de leur conversion en euros.
Que l’on parle de jours, d’heures, ou de points (de toute façon représentation relative d’un temps), je ne vois pas comment suivre efficacement un projet sans se préoccuper du reste à faire, du consommé.
J’ai trouvé dans Scrum une manière particulière et innovante d’intéresser les développeurs à ce qu’ils font, par le fait des les responsabiliser. Non pas pour les culpabiliser, mais les rendre responsable au sens propre du terme.
Se passer du burndown et donc de ses données intrinsèques me parait un risque majeur sur la compréhension et l’adhésion des équipes, voir des clients à la méthodologie Scrum.
