Suivre

SCRUM et les mêlées quotidiennes

framablog.org/2019/11/08/scrum

Dans cet article, Matt, développeur à Los Angeles, s'attaque aux "daily standups", ces réunions de la méthodologie SCRUM, très à la mode actuellement. Sous ce terme se cache une réunion quotidienne d'au plus 15 minutes, se déroulant normalement debout, qui a pour but la synchronisation de l'équipe. La traduction

@Framasoft je suis perplexe sur le but de l'article, ce n'est pas une question ou une demande de partage d'expérience, si? (Une demande de revue de code qui n'a pas été vue/prise dans le canal slack le jour précédent peut-être rappelé par un dev aux autres pour savoir si quelqu'un a le temps aujourd'hui)

@Framasoft Hello ! Avec tout le respect que je vous dois, j'ai plein de choses à redire sur cet article. Si vous me permettez la critique :).

----

Déjà pourquoi prendre comme source Atlassian alors que le livre blanc Scrum donne les directives ?

Par exemple quand l'auteur cite :
> une mêlée quotidienne est une réunion qui implique l’équipe de base : les propriétaires du produit, les développeurs et le facilitateur SCRUM.

Non, ça implique uniquement l'équipe de développement

@Framasoft

C'est spécifié en page 12 dans le livre blanc : scrumguides.org/docs/scrumguid

> Le Scrum Master veille à l’application de la règle stipulant que seuls les membres de l’Équipe de Développement participent à la mêlée quotidienne.

Déjà ça part mal pour l'explication d'Atlassian :(

@Framasoft Mais heureusement les 3 points dressés par Atlassian sont en phase avec le livre blanc. C'est cool !

Seulement l'auteur revient sur un paragraphe et explique ceci :

> Ok, donc fondamentalement, le seul intérêt des mêlées quotidiennes est de « maintenir tout le monde enthousiaste » ?

Erf, non… C'est faire fi de ce qui est expliqué dans la première phrase qu'il cite : « Ces questions mettent en lumière les progrès et aident à identifier ce qui bloque l’équipe. ».

@Framasoft Donc là, on voit que l'auteur néglige expressément tout le reste de ce qu'il cite. Dommage.

Ensuite, il dit : « Nous devrions être enthousiastes et nous sentir chanceux de disposer de tables de ping-pong, ». C'est bizarre, quel lien devrions-nous voir entre ces pratiques et la méthode SCRUM donc ?

Surtout qu'il dit ensuite :
> mais cet argument en particulier pour les mêlées quotidiennes me frappe telle la carotte au bout du bâton du micro-management.

@Framasoft Micro-management ?

Bah non, SCRUM est tout le contraire. Il suffit de regarder page 6 et 7 du livre blanc :

@Framasoft Le livre blanc parle expressément d'auto-organisation et de responsabilisation de l'équipe dans son ensemble. Il me semble que c'est antinomique du micro-management.

@Framasoft

Ensuite l'auteur revient sur les 3 points abordés lors des mêlées et contre-argumentent leur utilité :

Voici donc les contre-arguments :

> - Jira, Trello, Asana, les post-it sur le mur, ou discussions sur Slack
> - Jira, Trello, Asana, les post-it sur le mur, ou discussions sur Slack
> - Ils devraient alerter le reste de l’équipe immédiatement

@Framasoft Sauf que ce n'est pas exprimer l'avancement de l'équipe mais celui de l'individu. C'est bien dommage car la nuance est importante. Il s'agit de prendre de la hauteur par rapport à la réalisation des dernières 24h !

Et pour le dernier point, c'est nier l'existence de l'effet tunnel et de la nécessité de s'en rendre compte avec le board. Plus encore d'identifier les points de blocage en cours ou à venir avec cet outil et d'en discuter après la mêlée.

@Framasoft Enfin, l'auteur présente son point de vue :

> Vous voulez dire comme un point quotidien des tâches de chacun de la veille et du jour, sans compter les quasi-omniprésentes digressions ? Ce genre d’interruption ?

On parle d'une petite réunion de 15 minutes MAXIMUM ? :)

@Framasoft Et l'auteur de conclure :
> Soyez asynchrones, et supprimez les mêlées quotidiennes. De toute manière, elles ne servent à rien.

Ouais, sauf qu'il me semble se contredire plus haut : 

> Les points bloquants doivent être traités immédiatement.

De toute façon, un·e développeu·r·se n'a pas vraiment vocation à s'isoler complètement. Iel travaille en équipe. Et pour aider un·e collègue, iel devra consacré sans doute bien plus que 15 minutes pour ça. Il y a pire comme interruption.

@Framasoft

Navré, j'ai pas été tendre avec le contenu de l'article, et j'espère ne pas avoir manqué de bienveillance.

J'espère que ma critique est éclairante et éclairée, et courtoise (autrement je m'en excuse). Je pense aussi qu'il y a aussi des critiques à adresser à mon thread en retour, n'hésitez pas.

J'ai mon conflit d'intérêt, pratiquant la méthode SCRUM depuis plusieurs années.

@Framasoft Je ne nie pas que SCRUM puisse poser des inconvénients.

Seulement j'attends des arguments factuels et plus justes :).

Peut-être aussi l'auteur a mal vécu l'implémentation de la méthodologie. On peut le comprendre, beaucoup d'entreprise pratique très mal SCRUM ou l'agilité, et cela peut être très néfaste aux personnes de l'équipe.

Enfin, si vous m'avez lu, merci, et surtout merci pour votre travail fabuleux ! 🤘

@florent @Framasoft
Je ne suis pas défenseur du SCRUM, pour les dérives (à commencer par la description d'Atlassion) que causent des méthodes « clé en main ».

La remise en question est légitime, mais n'apporte pas de solution concrète : l'auteur aurait pu passer davantage de temps à mettre en exergue, et remettre en question les avantages de la pratique qu'il veut défendre.

@florent @Framasoft

Je comprends et j'adhère à la critique sur le côté infantilisant et déresponsabilisant de certaines pratiques de la méthode SCRUM.

Cependant quant aux « mêlées », je défends l'intérêt d'avoir une routine de travail, et un rythme pour chaque chose. Critiquer (je crois ?) les notifications incessantes de Slack et suggérer de travailler de manière asynchrone relève d'un comble.

@florent @Framasoft

En revanche, selon moi, le véritable point problématique dans ces réunions quotidiennes SCRUM, c'est la pertinence de tout ce qui y est dit.
Par exemple, s'interdire de discuter à deux, de partir sur une digression, pour garder des réunions a minima intéressantes pour tout le monde. Et éviter de parler pour soi.

Ce qui est sans doute les problèmes que l'auteur a perçu, mais a tenu à généraliser dans un format indélicat.

@luka @Framasoft Si tu as des sources sur ce que tu expliques, ça m'intéresse ! :)

@florent @Framasoft
Ahah, c'est là que je dis quelque chose qui est interdit, mais c'est ma propre expérience :p

Sur les critiques/solutions que je propose, c'est des choses que j'ai eu l'occasion de tester avec des équipes, pour converger sur des méthodes qui m'ont parues plutôt optimales.
Mais il faut tester les méthodes, essayer de changer, à chaque fois que l'équipe change aussi. Parce qu'une méthode ne marche que pour une topologie d'équipe (chaque arrivée, chaque départ, etc…).

@florent @Framasoft

De la même manière, il est très probable que mes conseils ne soient pas valables dans d'autres équipes.

Finalement, au même titre que la méthode SCRUM, ou autres méthodes clé-en-main préconstruites.

Inscrivez-vous pour prendre part à la conversation
Framapiaf

Mastodon est un réseau social utilisant des protocoles Web ouverts et des logiciels libres. Tout comme le courriel, il est décentralisé.