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.

Commentaires

1. Le lundi 17 novembre 2014, 17:43 par msieur_tim

Bonjour,

Je partage beaucoup de tes remarques.

Je trouve par contre les mots "deprecated" et "mieux" sont un peu forts : N'y a t-il pas des contextes sur lesquels les pratiques "dépréciées" sont encore judicieuses ? Est-ce si évident que ça ?

Je m'adresse ici à ceux qui sont dans la période Shu du Shu Ha Ri et qui suivent ces pratiques pensant qu'il s'agit du Scrum de base. C'est pour ça que j'utilise des mots "forts". Mais bien sûr je ne voudrais pas tomber dans un autre dogmatisme. Dans quel contexte penses-tu qu'une de ces pratiques est judicieuse ?

Une dernière chose : est-il possible de développer cette phrase ?
"Exiger un engagement sur un périmètre fonctionnel produit inexorablement soit de la dette technique, soit de la perte de motivation."

Dans un sprint, la date de fin ne change pas et l'équipe est stable. Si on s'engage sur un périmètre sans prendre de mou, il n'y a pas de variable d'ajustement pour les obstacles ou les urgences qui arrivent toujours pendant le sprint. Alors, soit l'équipe, en particulier si elle est a de la pression, va chercher à finir à tout prix les stories, et la dette technique apparaît, soit elle perd sa motivation, considérant que les conditions de son engagement ont changé.

Merci pour l'article (et pour les bouquins bien sûr).
Vive les châtaignes.

2. Le mardi 18 novembre 2014, 10:22 par Nicolas

J'aurai également ajouté l'estimation des tâches en heures comme pratique obsolète. Le mieux est de ne pas perdre de temps à les estimer.

Oui, c'était pour moi inclus dans le burndown, mais tu as raison, je vais en faire un sujet à part dans un autre billet D'autres pratiques Scrum obsolètes
3. Le mercredi 19 novembre 2014, 11:36 par cornel

Bonjour,

« Engagement de sprint sur des points ou des stories»

Si on est d’abord agile et après Scrum, la partie engagement sur un périmètre n’exclut pas la confiance qu’on donne aux développeurs d’assurer une meilleure qualité. Quand on dit « Les individus et leurs interactions plus que les processus et les outils » on pense d’abord à la confiance et aux développeurs renforcés, qui peuvent arrêter la ligne de production.
L’engagement sur un but, n’est pas plus efficace que l’engagement sur les PBIs. C’est pour cela aussi que le terme « commitment » a été changé avec « forecast » dans le guide Scrum. Le but du sprint n’est pas là pour faire l’équipe s’engager mais pour lui donner une flexibilité dans les choix qu’elle devra faire pendant le déroulement du sprint. Donc pour guider l’équipe.

Merci,
Cornel

Merci à toi. Ma position sur l'engagement est décrite dans ce billet.
4. Le mercredi 19 novembre 2014, 17:16 par Éric

J'avoue que la remarque sur le burndown m'étonne. Ça ne coute rien à faire, tout juste 30s par jour après ou avant le daily.

J'y trouve un aspect motivation et implication, plus synthétique que le tableau lui-même.

La valeur est faible, mais vu que le coût est nul, le solde est facilement positif :)

Si ça te convient, continue. Pour appuyer le commentaire de Nicolas, la pratique dépréciée est le burndown chart de sprint en heures (cela a plein de coûts cachés). Si c'est en tâches, en stories ou en points, effectivement le coût est moindre, en particulier pour les développeurs.