Série - Pratiques Scrum obsolètes

Fil des billets - Fil des commentaires

Pratiques Scrum obsolètes

[deprecated]

Je constate que des pratiques Scrum sont encore utilisées alors que je les considère, et beaucoup d'autres avec moi, comme obsolètes. Et depuis longtemps, puisque la plupart de celles que je cite ci-dessous étaient déjà dépassées quand j'ai écrit la première version de mon livre, sortie en 2010.

Mais l'histoire du focus factor nous avait montrés que les habitudes ont la vie dure.

Burndown chart de sprint

[deprecated] : Le scrumMaster élabore un burndown chart de sprint pour vérifier la situation par rapport à la droite idéale.

Mieux -> Le burndown chart de sprint est un indicateur pauvre. Il apporte peu pour ce qu’il coûte. En particulier s’il est fait en heures. Une équipe qui a un tableau et le met à jour régulièrement n'a vraiment pas besoin d'un burndown chart pour constater des déviations par rapport au but du sprint.

Estimations pendant la planification de sprint

[deprecated] : L'équipe fait du Planning Poker pendant la réunion de planification de sprint.

Mieux -> Si on estime les stories pour élaborer et mettre à jour un plan de release, c'est plus tôt qu'il faut le faire, lors de la revue de backlog. Si on estime juste pour calibrer le sprint, on peut sûrement s'en passer : #noEstimates.

Revue au PO

[deprecated] : Lors de la revue, l'équipe fait la démo au PO.

Mieux -> On ne montre à la revue que les stories finies et donc déjà acceptées par le PO, qui les aura validées avant, pendant le sprint. En plus c’est lui qui anime la revue. Il est dans l’équipe, pas contre elle.

Rétro et revue mélangées

[deprecated] : Pendant la revue, l'équipe tente d'expliquer aux parties prenantes les raisons pour lesquelles elle n'a pas atteint ses objectifs.

Mieux -> La revue est réservée à des discussions sur le produit. Les problèmes, obstacles seront évoqués lors de la rétrospective, avec l'équipe seule.

Engagement de sprint sur des points ou des stories

[deprecated] : l'équipe s'engage à réaliser x points (ou y stories) pendant le sprint.

Mieux -> L'équipe s'engage sur un but. Exiger un engagement sur un périmètre fonctionnel produit inexorablement soit de la dette technique, soit de la perte de motivation.

Ecrire les stories

[deprecated] : les développeurs attendent que le Product Owner écrive les stories.

Mieux -> On ne rédige pas une story, et le PO n'en est pas le seul responsable. Les stories sont raffinées, groomées, cultivées, lors des conversations entre le PO et les développeurs.

D'autres pratiques Scrum obsolètes

Péniche et platanes du canal du Midi

Mon billet précédent sur les pratiques Scrum obsolètes a été beaucoup lu et a provoqué des réactions intéressantes. Avec le même objectif, je récidive avec d'autres pratiques que je considère, pour la plupart des équipes Scrum, comme dépréciées.



Estimation des tâches en heures

[deprecated] : Les développeurs estiment les tâches en heures et mettent à jour régulièrement le reste à faire.

Mieux -> Comme le disait Nicolas en commentaire du billet en question, il n’est pas utile de faire d’estimation des tâches en heures ou en jours. Si on veut un indicateur de suivi, on les compte.

Excel pour le backlog.

[deprecated] : Le Product Owner gère son backlog sous excel.

Mieux -> Le backlog est partagé avec toutes les parties prenantes. Il est bien visible et présenté en petits bacs.

Planification de sprint en 2 parties

[deprecated] : La réunion de planification du sprint comporte 2 parties distinctes et le PO ne vient pas à la deuxième, plus technique.

Mieux -> Historiquement le guide Scrum officiel distinguait bien 2 parties (d’une demi-journée chacune !).
D’une part, et heureusement, c’est plus court maintenant (notamment grâce à l’affinage préalable du backlog), d’autre part la présence du PO s’avère nécessaire jusqu’à la fin, en particulier pour ajuster le but du sprint et négocier lors de l’engagement.
Il est préférable d'organiser la réunion différemment, pour retarder les décisions sur l'engagement en fin de réunion, l'équipe connaissant mieux la situation.

Des slides sur l’avancement à la revue

[deprecated] : Pour la revue de sprint, l’équipe élabore des slides montrant l’avancement pendant le sprint et la situation du développement du produit.

Mieux - > Donnez aux participants les informations qui les intéressent vraiment, éventuellement en organisant la revue différemment. L’avancement pendant le sprint ne devrait pas intéresser les utilisateurs. Pas besoin d’élaborer des slides si vous pratiquez le management visuel.

Une colonne à tester sur le tableau des tâches

[deprecated] : L’équipe ajoute une colonne à tester dans son tableau.

Mieux -> Une équipe Scrum qui pratique bien l’essaimage n’a pas besoin de cette 4ème colonne, source de multi-tâches et donc de perte de temps.