Temps de lecture 5 min
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 choisie ici est « mêlée quotidienne », mais on trouve aussi les appellations « Daily », « standups » ou réunions quotidiennes.
Source : The pointlessness of daily standups
Traduction framalang : Maïa, Côme, Evvin, Fabrice, Goofy et Marius
De l’inutilité des mêlées quotidiennes
Vos mêlées quotidiennes tuent votre productivité.
Peut-être est-ce de la naïveté ou peut-être est-ce seulement le fait d’avoir fait partie d’équipes où, c’est un point important à noter, personne (pas même moi) ne savait comment mener une mêlée quotidienne efficacement, mais je n’en ai jamais compris l’utilité. Ceci est doublement vrai si on prend en considération l’utilisation en parallèle d’outils tels que Jira ou Trello, couplés aux messages incessants que permet Slack.
Quelle est finalement l’utilité d’une mêlée quotidienne ? Si j’envisage de critiquer quelque chose, je préfère être certain de savoir de quoi je parle. J’ai une vague intuition de ce que doit être leur rôle, mais pour être complet, jetons (rapidement) un œil sur la description d’une mêlée quotidienne dans la documentation d’Atlassian :
[…] 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. Le style de cette réunion est propre à chaque équipe, mais chez Atlassian, nous utilisons trois questions simples pour la structurer :
- Sur quoi ai-je travaillé hier ?
- Sur quoi vais-je travailler aujourd’hui ?
- A quels obstacles suis-je confronté ?
… et un peu plus loin…
Ces questions mettent en lumière les progrès et aident à identifier ce qui bloque l’équipe. De même, cela renforce l’équipe car tout le monde partage les progrès qui contribuent à l’équipe. Le renforcement quotidien du partage des réussites et des plans individuels maintient l’enthousiasme collectif quant à la contribution globale de l’équipe à l’entreprise.
Ok, donc fondamentalement, le seul intérêt des mêlées quotidiennes est de « maintenir tout le monde enthousiaste » ?
… *** gros soupirs *** …
J’ai toujours eu l’impression que l’industrie aime traiter les équipes de développement comme une bande d’ados stupides. Permettez-moi de m’étendre là-dessus…
Nous devrions être enthousiastes et nous sentir chanceux de disposer de tables de ping-pong, d’en-cas gratuits, de jours de congés pour les anniversaires (avec durée indéterminée, pour écraser l’altruisme), et maintenant, d’être capable de voir les progrès de chacun ? Comprenez-moi bien, je ne suis pas cynique à ce point-là, mais cet argument en particulier pour les mêlées quotidiennes me frappe telle la carotte au bout du bâton du micro-management.
Peut-être que cela enthousiasme certains, et peut-être même que des gens en tirent des bénéfices. Je dirais plutôt qu’ils n’utilisent pas leur panoplie d’outils à leur maximum, mais passons, je leur laisse cela. Cependant, je préfère m’intéresser au ratio coût/bénéfice des mêlées quotidiennes et alors votre équipe pourra prendre une décision sur ces calculs.
Mettons de côté pour un instant le « facteur d’enthousiasme » qui n’est pas quantifiable. Nous devons être capables de régler les points suivants :
- Qu’a fait un membre de l’équipe hier
- Que fait un membre de l’équipe aujourd’hui
- N’importe quel élément bloquant qu’un membre de l’équipe rencontre
… d’accord, j’allais écrire un paragraphe ou deux sur ces points, mais je vais m’en remettre à Cervantes pour ce coup-ci :
Sois bref dans ton discours, car ce qui est prolixe ne peut être agréable
(Intelligence et sagesse de Don Quichotte)
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
Les deux premières réfutations ne nécessitent pas de clarification j’espère. Pour le dernier point, soyons honnêtes, si vous êtes bloqué⋅e sur quelque chose et que vous attendez la prochaine mêlée pour prévenir le reste de l’équipe que vous êtes bloqué⋅e, d’autres soucis de communication doivent être pris en compte. Les points bloquants doivent être traités immédiatement.
« Attendez une minute ! », pourrait-on me dire, « cela va déranger l’équipe si les gens sont interrompus à cause d’un point bloquant ! ». Déranger l’équipe ? 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 ?
Je n’en vois pas le bénéfice global. J’argumenterais que la perte d’attention est plus probable que l’intérêt de savoir sur quoi travaille quelqu’un d’autre. Réellement. Réfléchissez-y. Combien de fois retirez-vous des informations utiles de vos mêlées (que vous n’auriez pas pu obtenir de vos outils de suivi de projet), par opposition à la perte de contexte de votre propre travail et — pour finir — par rapport à l’attention consacrée à des digressions qui devraient se dérouler en dehors des réunions ?
Vous voulez une équipe plus efficace ? Vous voulez des plages de concentration plus longues pour avancer sur les tâches de votre sprint ?
Soyez asynchrones, et supprimez les mêlées quotidiennes. De toute manière, elles ne servent à rien.
À propos de l’auteur
Matt est un développeur frontend qui vit (et skate) à Los Angeles. Il développe en React et en TypeScript, mais s’intéresse beaucoup aux langages bas-niveau (Rust, C++, C, …).
Il est joignable via Mastodon ou Twitter
Benjamin
Léger manque de clairvoyance sur ce qu’est Scrum… Revenons à l’essence de cette méthodo qui est de délivrer des produits (de valeur), et surtout complexes. Par complexité on entend qu’il y a une forte incertitude sur ce que l’on doit réaliser (car on doit le découvrir en itérant) et sur la façon de le réaliser.
Dans un contexte complexe on part du principe que l’ensemble des membres de l’équipe sont utiles à faire avancer le projet. Du coup il n’est pas question de travailler seul dans son coin. Et du coup vous avez raison de dire qu’on se fout de faire du reporting individuel.
Mais ce que vous décrivez c’est la façon merdique de faire une mêlée, par des équipes qui ne comprennent pas Scrum.
Changer l’exercice en prenant votre backlog de sprint items par items. En commençant par ce qui est déjà en cours de dev et le plus proche d’être complété. Et posez la question suivante: « Que doit-on faire pour terminer ce travail ? As-t-on tout ce qu’il faut ? Es-t-on en difficulté ? »
Ce faisant, on parle du travail en cours, pas de ce que les individus font. On parle des objectifs communs de l’équipe, on identifie des points de blocage et favorise l’entraide. Cette pratique se nomme « walk the board » et on la voit plutôt dans des univers Lean que Scrum. C’est pourtant la meilleure façon d’avoir une mêlée utile.
Maintenant si on bosse sur un projet/produit où le travail n’est pas forcément complexe et que les personnes sont autonomes et travaillent dans leur coin… Scrum ça sert à rien. Donc oui ce rituel ne servira à rien.
By the way, citer Atlassian n’est certainement pas la meilleure source pour parler d’agilité 🙂
Lyz
C’est, je pense, le principal souci des méthodes de ce genre : c’est à la mode, « chez Untel ça marche » donc on voit débarquer ça partout, mais mené par des gens qui n’y comprennent rien et qui oublient d’adapter aux besoins réels du projet.
Y compris dans les projets libres. J’ai eu quelques enthousiastes qui, ayant expérimenté avec succès les méthodes agiles dans leur entreprise, souhaitait mettre ça en place en débarquant sur un projet, sans prendre en compte que l’environnement était complètement différent, et surtout qu’avoir été participant ne faisait pas d’eux des experts du sujet. Résultat, on installe des kanboards, on fait des réunions « façon agile » et puis, quelques mois plus tard… les anciennes façons de faire se sont réinstallées, les kanboards n’ont jamais servi, et personne n’a vraiment fait ce qui avait été dit dans l’enthousiasme des premiers moments.
Ça ne veux pas dire que les méthodes sont mauvaises. Ça veut dire qu’elles ne sont pas miraculeuses, et qu’elles ne répondent pas à tout, surtout quand elles sont mal appliquées au mauvais moment sur les mauvaises choses. Et qu’il faut arrêter de bondir sur chaque mode manageriale et questionne la compétence de ceux qui viennent avec des mot-clés douteux…
Winael
Bon mettons clairement les points sur les I.
Scrum N’EST PAS une méthode. C’est un cadre de processus léger pour la résolution de problèmes complexe et iteratif dont les règles du jeu sont décrites dans un guide (le guide Scrum), gratuit, dispo en pdf et en plusieurs langue et accessible en 3 secondes via Google et qui ne fait que 26 pages.
Ceci étant dit, la mêlée quotidienne sert à l’équipe de développement complexe qui n’est pas obligée d’utiliser des outils numériques, d’échanger des informations dans une optique d’inspection/adaptation pour s’assurer que l’objectif du sprint visé est toujours atteignable, et à signifier les obstacles. S’il y a besoin de discuter plus de point tech ou de rediscuter de point de conception, c’est juste après cette cérémonie.
On est pas obligé en Scrum d’être debout (les équipes distribuées le font assis derrière la webcam, voire ont peu très bien se rejoindre sur un salon slack dédié), certains même le font sur les coudes abdos contractés (histoire de travailler le corps et de ne pas dépasser 15 minutes)
Certaines équipes travaillent sur les éléments du backlog en essaim. Dans ce cas chaque essaim, designe un porte-parole (jamais le même) pour expliquer brièvement sur quoi l’essaim a travailler sur quoi il va avancer et éventuellement les points de blocage.
Bref l’équipe étant autonome et auto-organisées, elle choisit le format qui lui convient. Le PO n’intervient pas durant cette cérémonie (il peut écouter si l’équipe l’accepte, mais ce n’est pas du reporting). Le SM doit s’assurer que cette cérémonie est lieu, peut être observateur pour aider l’équipe à progresser sur cette cérémonie.
Malheureusement on voit encore trop de dev ou d’ops qui utilisent des outils ou framework sans savoir comment ils fonctionnent et sans faire l’effort de se renseigner un minimum et qui critiquent sans connaître.
Scrum n’est pas parfait, mais c’est un bon point d’entrée pour mettre en place l’Agilité et DevOps dans les équipes, le but étant de dépasser Scrum au bout d’un certain temps lorsque l’équipe est jugée assez mature. Et c’est un Ops qui parle ^^
Benjamin
@Winael, ça me fait toujours marrer ce débat sur méthode versus cadre.
L’agilté est bien un état d’esprit, un cadre avec des principes et valeurs. Ce cadre doit nous permettre une lecture critique de la façon on travaille. Mais Scrum est bien une implémentation méthodologique de l’agilité.
Définition de « méthode » dans le monde du travail : « Ensemble de démarches raisonnées, suivies pour parvenir à un but. »
Scrum est prescriptif dans son approche : il définit les évènements, les artefacts et les rôles. Il laisse toutefois une grande part de liberté, mais ça n’en reste pas moins une approche méthodologique.
Florent
J’ai rédigé un long thread pour répondre à cette critique de SCRUM, car il me semble qu’elle est mal argumentée.
https://mastodon.zeteo.me/@florent/103104658387374680
Claude Aubry
En tant que soutien fidèle de Framasoft depuis des années, je suis surpris et déçu que l’équipe Framalang ait choisi de traduire et publier cet article. J’ai regardé la ligne éditoriale et les articles précédents publiés sur le Framablog, notamment ceux sur les communs. De mon point de vue l’agilité fait partie du même mouvement, en particulier avec son accent mis sur le collectif. Le pouvoir est donné à l’équipe.
Alors évidemment il existe du faux agile comme celui raconté dans cet article, mais il s’explique le plus souvent par la persistance d’une culture industrielle (héritée du taylorisme) dans les organisations.
L’argument de la perturbation provoquée par la mêlée quotidienne est recevable ; cependant la tenir tous les jours à la même heure en fait un rite fondamental pour devenir une véritable équipe. Et les rites sont utiles pour bien démarrer. Il faut des rites, comme dit le Petit Prince.
Bref, l’agilité (dont Scrum fait partie) met en avant des valeurs qui sont probablement en phase avec celles défendues par Framasoft. Elle mérite mieux que ce billet, dont Florent, Benjamin et Winael ont bien montré la faiblesse. Merci à vous.
Meg
J’ai un peu de mal à voire le rapport entre la vocation que se donne Framasoft (le libre et sa philosophie) et l’article en question. Je dis pas qu’il ne faut jamais diverger. Mais là, ça arrive vraiment comme un cheveux sur la soupe. Ça fait un peu le même effet que si Futura-science publiait un article sur les relations de Lætitia Halliday avec Johny.
D’autant que c’est un article qui est quand même vachement spécifique (je suis pas sûr qu’il y ait grand monde en France qui ait déjà participé à une “mêlée quotidienne”, voire qui en ai déjà entendu parlé). Du coup, même si l’article avait été pertinent (j’utilise un conditionnel, car d’après les commentaire précédents, il semble que ce ne soit pas le cas. Moi, j’en sais rien, j’ai jamais fait de SCRUM de ma vie), ben on se demande un peu ce qui se passe chez Framasoft et pourquoi ils nous causent management.
Vincent Carluer
Voilà mes contres contres arguments à ce petit troll :
* « Jira, Trello, Asana, les post-it sur le mur, ou discussions sur Slack »
-> Tous ces exemples sont de l’information qu’il faut aller tirer si on y pense, quand on y pense (en gros ce n’est pas fait). Le stand-up est de l’information poussée et diffusée à tous sur un court temps qui permet de se synchroniser
* « Ils devraient alerter le reste de l’équipe immédiatement »
-> L’hypothèse de départ posée est fausse. Généralement on n’est pas bloqué et ce n’est pas de cela dont on parle, mais en recherche et en difficulté car cela fait parti du métier, et l’évoquer à tous permet souvent d’avoir de nouvelles idées rapidement pour trouver la solution
Jérôme Dautzenberg
Moi je suis un vieux con qui ne travaille plus dans la partie depuis fort longtemps. La mêlé quotidienne pour échanger des informations transversales debout on appelait ça «prendre le café» et ça se situait souvent aussi assis à la cafétaria. Je faisais du service après vente en clientèle, donc ces réunion cordiales était très utiles, que ce soit sur le plan technique ou relationnel, au fonctionnement d’une équipe de gens souvent seuls dans leur coin.
Après en tant que vieux con dépassé, je suis assez halluciné par le langage utilisé au dessus pour décrire le phénomène : Je suis partagé entre sorte d’urgente nécessité d’aller réécouter soit Jacques Lacan, soit Franck Lepage, j’hésite, j’hésite…
eioznfioze
Ah non ! Les mêlées c’est 15 minutes, le café c’est bien plus long 🙂
Aris
Pour avoir participé à quelques stand-up sur des projets aux-quels j’étais associé, je trouve ce retour critique très intéressant. Très intéressant, ne veut pas dire que je sois forcément d’accord. Intéressant, parce qu’il interroge ce qui est devenu un lieu commun du micro-management de projets, et que sous les apparences “cool” et “agile” il s’agit bien très souvent d’encadrement entrepreneurial.
Le stand-up c’est de l’organisation, mais c’est aussi et surtout de l’idéologie: un moyen de motiver et d’encadrer… en faisant avaler des couleuvres à l’équipe s“il le faut, pour que la production avance à marche forcée. Par exemple, la solution retenue à tel problème de traitement de données, sera celle qui combine la faiblesse des coûts et le respect du planning de mise en production… pas forcément celle qui est la plus cohérente au niveau du code, et/ou la plus fonctionnelle pour les utilisateurs et utilisatrices.
Ce texte a donc ce mérite: la bousculer la béatitude de la fausse évidence de ce genre de procédure. Puisque cela fonctionne ailleurs, on vas faire des stand-up quotidiens et tout sera réglé… Ben, dans la vraie vie, c’est pas vraiment comme cela.
Sinon, j’ai vraiment été gêné par le choix de traduire stand-up par “mêlée quotidienne” qui me semble nuire à sa compréhension. IRL personne ne dit “mêlée quotidienne” mais “stand-up”. Cela me semble relever de la novlangue managériale.