SCRUM et les mêlées quotidiennes

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