Challenge ton Daily !

Je souhaite vous partager quelques réflexions qui me sont venues lorsque j’ai été amené à me replonger dans les arcanes du framework agile Scrum à l’occasion d’un récent passage de certification agile.

En relisant le guide Scrum (mis à jour en 2020, ça m’avait échappé) et quelques articles de référence sur le domaine, il m’est devenu évident que, dans ma pratique de Scrum et mon rôle de Scrum Master, une routine s’était installée dans certaines cérémonies à l’intérieur de mon équipe actuelle. Cela n’est jamais très bon quand on met en place une méthodologie qui repose en grande partie sur l’introspection régulière et l’amélioration continue. Au delà de ces habitudes qu’on ne challenge plus, la bascule en télétravail plus ou moins total au gré des vagues virales a apporté son lot de contraintes et d’évolutions dans les pratiques, qu’il convient de challenger également.

Dans cet article, je vais me concentrer sur la cérémonie emblématique, le « Daily », et voir en quoi on peut/doit envisager de bousculer certaines pratiques.

Retour aux sources : au fait, à quoi sert le Daily ?

Reprenons le Scrum Guide de 2020.

La raison d’être du Daily est d’augmenter les chances de livrer en fin de Sprint un incrément aligné avec ses objectifs.

Lors de cette cérémonie, les développeurs suivent leur progrès vis à vis des objectifs du Sprint et leur capacité à livrer un incrément qui respecte les critères de la Definition of Done. Ils planifient leur travail pour les 24 heures qui suivent (c’est à dire jusqu’au prochain Daily).

C’est un évèment « timeboxé » qui ne doit pas dépasser les 15 minutes (au risque de voir la cérémonie désertée par ses participants pour ne pas « perdre de temps à ces réunions sans fin où les bavards causent trop« ).

Ce n’est pas une instance où l’on règle les problèmes, mais une instance où on identifie les éléments perturbant le projets. Les discussions qui nécessitent un temps plus long pour traiter un problème font l’objet de réunions spécifiques avec uniquement les personnes pertinentes.

A partir de ces éléments, on peut challenger ses habitudes.

Non, le Scrum Master ne participe pas forcément au Daily

Cela fait 2 ans que je travaille en tant que Scrum Master sur le projet qui m’occupe à l’instant où j’écris ces lignes, et les Daily que j’ai ratés doivent se compter sur les doigts d’une main (l’équipe corrigera peut être ma mémoire dans les commentaires de cet article :-)).

En effet, j’ai toujours considéré que la présence du Scrum Master au Daily était obligatoire…. car c’est toujours ce que j’ai vu dans les projets agiles auxquels j’ai participé (et que c’est un travers d’ex chef de projet ?). Et en fait, non, cette présence n’est pas obligatoire. Le rôle du Scrum Master est de s’assurer que la cérémonie ait lieu et qu’elle se déroule dans un esprit qui permet d’atteindre ses objectifs. Les seules personnes obligatoires pour cette cérémonie sont les développeurs, qui doivent être responsabilisés dans tout projet agile. On ne va pas au Daily pour faire plaisir au Scrum Master !

Donc, sauf si le Scrum Master participe également au projet avec une casquette de développeur, sa participation est optionnelle.

Tant qu’il s’assure que les Daily ne sont pas zappés par l’équipe, qu’il participe à quelques instances régulièrement pour s’assurer que la cérémonie n’est pas dénaturée ou qu’elle ne dépasse pas allégrement la limite de 15 minutes, la méthodologie est respectée. On pourra donc, en tant que Scrum Master, commencer un projet en participant à tous les Daily pour s’assurer que la cérémonie est bien comprise par tous (d’autant plus important si l’équipe est peu expérimentée en Agile), puis alléger progressivement sa participation, tout en restant disponible et réactif pour lever les obstacles que peut rencontrer l’équipe de développement.

Non, un Daily ne se tient pas forcément le matin pour démarrer la journée

Voyageons 1 à 2 ans en arrière. Vous vous rappelez, les Daily au saut du lit quand on était tous confinés ? On devinait le pyjama en dehors du cadre de la caméra. Trêve de plaisanterie, la plupart des équipes fonctionnant en Scrum utilisent un créneau matinal pour caler leur Daily. C’est assez intuitif : on parle alors de ce qu’on a fait la veille, de ce que l’on va faire dans le jour qui arrive, jusqu’à la fin de la journée. Cela a aussi l’effet collatéral d’inciter les personnes pas très matinales à ne démarrer leur journée trop tard (ah, que de conflits sur ce sujet dans le passé…), et donc de s’assurer d’un maximum de plages de travail en commun.

Mais essayons de nous placer dans un autre cadre (c’est l’objet de cet article), et imaginons que l’on fasse ce Daily à 18h, en toute fin de journée donc.

Cela a plusieurs avantages :

• si je dois parler de ce que j’ai fait dans les 24 dernières heures, ou des problèmes que je rencontre dans le projet, c’est très frais pour moi, puisque toute une nuit ne s’est pas écoulée (combien de Daily où quelqu’un dit « euh, qu’est ce que j’ai fait hier, et bien, attendez, je ne sais plus… »). Accessoirement, je parle de mes soucis en fin de journée, cela permet parfois d’avoir une réponse immédiate sur les problèmes simples (cela ne s’applique pas aux gros problèmes, voir au-dessus), et donc de passer une meilleure nuit, avec moins de charge mentale !
• je donne plus de liberté aux acteurs de l’équipe pour gérer leur temps en début de journée, et je pallie aux impondérables qui amènent parfois à arriver en retard aux Daily matinaux (train/métro en panne, les enfant à amener à l’école…)
• cela amène chacun à planifier sa journée du lendemain en cohérence avec les autres, et donc de démarrer la journée suivante en toute indépendance des horaires des autres (les personnes matinales me comprendront, ici), et je maximise ainsi ma productivité

A tenter, donc, même si bien évidemment ce n’est pas parfait ou adapté à toutes les équipes.

Il y a des alternatives aux « 3 questions »

Traditionnellement, un Daily se traduit concrètement par une enchaînement de réponses de chaque participants aux 3 questions classiques : « qu’ai-je fait depuis le dernier Daily ? », « que vais-je faire jusqu’au prochain Daily ? », « est ce que je rencontre des problèmes ? ». Lassant.

Depuis la mise à jour 2020 du Scrum Guide, il n’est plus obligatoire de traiter le Daily avec cette approche. Ce qu’impose le Scrum Guide, c’est que l’équipe établisse collectivement son plan d’action jusqu’au prochain Daily dans l’optique de se rapprocher des objectifs du Sprint. Elle le fait avec un formalisme totalement libre, rien n’est imposé.

Je pense notamment que s’affranchir de la question « qu’ai-je fait hier » peut aider à éviter une dérive du Daily vers un « Status Report Meeting » où chacun consacre de l’énergie à mettre en valeur le travail réalisé la veille vis à vis de l’équipe ou vis à vis d’un chef imaginaire (pour rappel, le Scrum Master n’est pas un chef auquel on doit des comptes mais un « serving leader »). L’effort est porté sur ce que l’on va réaliser pour avancer dans le Sprint, ce qui est le plus important pour le projet.

Get up, stand up (don’t give up to fight)

Dans certaines organisations, on se réfère au Daily par le terme « Stand up ». Cela provient des origines de l’agilité où l’on se réunissait devant un tableau de post-it qui représentait le Sprint Backlog, dans un coin de l’open space, tous ensemble.

Ce qui est intéressant, c’est que cette cérémonie se fait traditionnellement debout (pour l’anecdote, le coach agile qui m’a formé à l’agilité interdisait même aux participants de poser une fesse sur un support). Non pas par goût de la station debout ou par sadisme, mais parce que cette station n’étant pas la plus confortable chez les humains, cela incite les participants à ne pas trop déborder de la timebox de 15 minutes afin de rejoindre au plus vite le confort douillet de leur fauteuil de bureau rembourré.

Et c’est là que j’en viens au confinement et autres pratiques intensives du télétravail, qui ont changé nos pratiques : étant tous présents « virtuellement » derrière notre session Teams, chacun participe au daily confortablement installé, et c’est là que la tentation est grande de prolonger le plaisir de l’échange au delà des fameuses 15 minutes, ou de laisser dériver les échanges sur de la résolution de problème (car cette cérémonie est souvent l’unique point de rencontre où l’on a toute l’équipe)

Dans ce contexte, on peut se challenger et :

• se lever devant l’écran ? De prime abord assez étrange, ce sera néanmoins un moyen de casser la routine, cela empêchera de faire autre chose avec le clavier quand les autres parlent (le respect est une des valeurs agiles fondamentales, rappelons le), et on tiendra plus facilement la timebox !
• créer des instances dédiées pour « socialiser », « créer du lien », quand les équipes sont éclatées physiquement. Cela permet de se concentrer sur les seuls objectifs du Daily sur 15 minutes, tout en partageant librement dans une autre instance qui ne parasite pas le daily.

Et maintenant ?

J’espère que vous ressortirez avec plein de questions sur votre pratique, que vous essaierez certains éléments ici décrits. Tout n’est probablement pas à prendre, chaque équipe et contexte étant différents, mais l’essentiel est de se remettre en question !

Selon les retours à cet article, il est possible que j’aborde les autres cérémonies dans un futur proche. Dans cette attente, n’hésitez pas à apporter d’autres idées dans les commentaires…