Pratiques Scrum obsolètes

Obsolescence programmée

Pratiques Scrum obsolètes
Sommaire

Je constate que des pratiques Scrum sont encore utilisées alors que je les considère, et beaucoup d’autres avec moi, comme dépréciées. 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, en 2009.

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

Lire l’histoire du focus factor.

Burndown chart de sprint

[deprecated] : Le Scrum Master é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 saison, c’est plus tôt qu’il faut le faire, lors de la revue (ou affinage) 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 et 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 objectif. 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 affinées, groomées, cultivées, lors des conversations entre le PO et les développeurs.

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 -> 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 les créateurs de Scrum distinguaient 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 l’objectif 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 4e colonne, source de multi-tâches et donc de perte de temps.

Voir aussi