C’est un sujet qui déclenche des passions lorsque je demande à un PO de ne plus intervenir pendant les dailies. Incompréhension, déni et autres sentiments s’entrechoquent alors. Le PO au daily, est-ce vraiment un anti-pattern ?

“Hein, mais c’est quoi cette histoire ?!”

C’est la réaction, unanime, que j’ai reçue il y a encore quelques jours face à un groupe de POs.

Incompréhension, déni …

Lorsque je demande à un PO d’arrêter de venir aux dailies, je me retrouve face à des sentiments très forts qu’il faut prendre en compte; rejet, perte de contrôle, etc.

Le PO peut se sentir abandonné, exclus
Le PO peut se sentir abandonné, exclus

Généralement, il me faut bien une à deux heures de discussion avec un PO pour le convaincre. Et encore, il n’est souvent pas vraiment convaincu mais juste à cours d’arguments.

Le Scrum Guide préconise-t-il le PO au daily ?

Scrum ne l’interdit pas plus qu’il ne le recommande. Le Scrum Guide indique que l’évènement est fait pour l’équipe de développement et décrit le daily comme suit :

“La mêlée quotidienne (Daily Scrum) est un événement de 15 minutes (time-boxé) destiné à l’équipe de développement.”

“La structure de la réunion est définie par l’équipe de développement”

“La mêlée quotidienne est une réunion interne pour l’équipe de développement. Si d’autres personnes sont présentes, le Scrum Master s’assure qu’elles ne perturbent pas la réunion.”

L’implication du PO pendant le daily est donc soit une méconnaissance du Scrum Guide, soit un choix délibéré (mais de qui ?!).

Si le PO au daily n’est pas la volonté expresse de l’équipe de développement, vous ne faites pas du Scrum. Ouch ! C’est dur !

Sa présence est un symptôme

Que le PO soit au daily, cela paraît être une bonne idée afin de se tenir au courant ou pour aider l’équipe de développement, alors pourquoi n’est-ce pas préconisé par le Scrum Guide ? C’est justement LES questions à se poser : Pourquoi ?

  • Pourquoi le Scrum Guide ne le préconise pas ?
  • Pourquoi le PO a-t-il besoin de participer aux dailies ?
  • Pourquoi l’équipe de développement a-t-elle besoin du PO aux dailies ?

La plupart du temps, l’équipe ne s’est pas posé ces questions parce que la réunion s’est créée ainsi, à cause d’une mauvaise lecture du Scrum Guide ou un manque de compréhension de l’implication. Voyons plus en détail.

Pourquoi le PO a-t-il besoin de participer aux dailies ?

C’est malheureusement souvent pour de fausses bonnes raisons :

  • être au courant de l’avancée du sprint
  • s’informer de blocages
  • répondre à des questions
  • etc.

Sauf que si le daily sert à se tenir au courant de l’avancée du sprint ou pour s’informer des blocages, le daily devient un reporting au PO. Il faut une sacré maturité de l’équipe entière pour éviter ça. Le backlog de sprint est l’outil à disposition de l’équipe de développement pour communiquer, il faut peut-être le compléter ?

Neuf fois sur dix ‒c’en est presque mécanique‒ tous les visages se tournent et parlent au PO, alors que le daily est un espace d’échange et de planification de l’équipe de développement.

C’est pour cela que je préconise toujours à mes équipes de s’organiser en arc de cercle autour du board.

Schéma d'une équipe autour de son board
L’équipe Scrum, autour du board, avec le PO et le Scrum Master en retraits

Quand le PO ou même le Scrum Master entre dans ce demi-cercle, c’est quasi certain que les conversations vont se faire vers cette personne. Ci-dessus, on remarque la zone “de partages et d’échanges” hachurée en jaune.

Le PO peut aussi demander à ce que le langage soit adapté. En effet, si le PO est là, il faut qu’il comprenne ce qui est dit (sinon aucun intérêt). L’équipe doit alors éviter des termes trop techniques et de l’information cruciale peut se perdre dans cette traduction. Cela peut impacter la capacité de l’équipe à planifier correctement le travail de la journée.

Si le daily est le moment d’énoncer ou répondre aux questions, le risque est grand pour que les questions de la veille restent en attente. C’est un symptôme d’une équipe qui ne communique pas de façon fluide. Le PO qui n’est pas disponible va pouvoir dire « on voit ça au daily demain, m’ok ? ».

Les questions de fonctionnement ou d’éclaircissement, doivent être posées au moment où elles émergent.

Si le PO n’est pas disponible à ce moment là, la question doit être posée au plus tôt.

Pourquoi l’équipe de développement a-t-elle besoin du PO aux dailies ?

Cas plus rare, c’est l’équipe de développement qui demande au PO d’être présent. C’est en parfaite conformité avec le Scrum Guide, puisque c’est elle qui est en charge de l’organisation de la réunion.

Par contre, si cela arrive régulièrement, cela devrait lever une alerte. Le Scrum Master devrait faire en sorte que l’équipe entière se demande pourquoi. Peut-être que les éléments du backlog ne sont, régulièrement, pas clairement définis ? Il y a sûrement des actions à prendre.

Il se peut bien sûr que l’équipe de dev ait une interrogation pendant le daily. C’est pour cela que j’aime demander que le PO soit toujours –pas seulement pour le daily– « à portée de voix » de l’équipe de développement.

L’équipe peut alors poser une question directement au PO pendant le daily si la réponse est nécessaire à la planification de la journée de travail. Sinon, je recommande plutôt de garder la question pour après le daily.

Attention toutefois qu’une résolution ne s’installe pas pendant le daily, qui n’est pas là pour ça.

Je recommande que les membres de l’équipe de dev qui sont intéressés par la réponse à la question, se retrouvent avec le PO juste après le daily (quitte à ce que ce soit toute l’équipe) pour discuter.

Pourquoi le Scrum Guide ne le préconise pas ?

C’est à mon avis pour ne pas tomber dans les travers décrit ci-dessus.

Le daily est un espace-temps de 15 minutes maximum (souvent moins). Je préfère pour ma part sacraliser ce court moment de planification, quitte à ce qu’une discussion complète avec le PO suive le daily quand c’est réellement nécessaire.

N’oublions pas que je parle ici d’une présence active du PO au daily. Le PO peut tout à fait se poser en tant qu’observateur du daily « non perturbateur ».

La taille de l’itération compte aussi

C’est un élément à prendre en compte. Plus l’itération est longue, plus le besoin de se tenir au courant et d’affiner les tâches du sprint se fera ressentir. Raccourcissez vos itérations ne peut faire que du bien (lire Devez-vous passer au Sprint d’une semaine ?)

“Pourquoi ressent-il le besoin d’y assister ?” est une question clé.

Si c’est pour « vérifier » ou « prendre de l’information » j’aurai tendance à essayer de trouver une autre solution pour arriver à lui donner plus de feedback.

Si c’est pour une autre raison, comme « je suis bien avec l’équipe j’ai juste envie d’être là » et que l’équipe n’y voit pas autre chose, il n’y a aucun problème, au contraire, il fait parti de l’équipe Scrum. Néanmoins, je ne le recommande que pour des équipes extrêmement matures.

Avec une communication fluide, l’équipe devrait aussi s’en passer non ?

Effectivement, si le daily n’est pas “le moment d’énoncer ou répondre aux questions” du PO, tel que décrit plus haut, pourquoi cela n’en serait pas de même pour toute l’équipe ?

La communication entre les développeurs devrait être aussi fluide qu’avec le PO non ?

Voici ce que le Scrum Guide écrit :

“L’équipe de développement planifie le travail pour les prochaines 24 heures. Cela optimise la collaboration et la performance de l’équipe tout en inspectant le travail depuis la dernière mêlée quotidienne et envisageant le travail restant durant le Sprint.”

Si le Scrum Master (ou l’équipe elle-même) se rends compte que le daily est utilisé pour poser des questions qui étaient en attente, il est impératif de se remettre en question et de comprendre ce qui a empêché les développeurs de se parler avant le daily.

Au même titre qu’avec le PO.

Sevrage

La présence du PO au daily est souvent une habitude bien ancrée et difficile à remettre en question. Pourtant, je recommande de le faire au plus vite pour s’assurer que ce comportement ne nuise pas à la bonne marche de l’équipe.

Et comment le vérifier ? Une première étape peut être de forcer un sevrage rapide en demandant au PO de ne pas venir aux dailies pendant quelques semaines. Pas même en tant qu’observateur et de voir ce qu’il en ressort.

Si le PO, ou l’équipe, ressentent un manque (d’information ou autre), c’est un bon point de départ pour travailler sur les palliatifs à long terme; par exemple en complétant le board avec plus d’informations (communication passive).

Conclusion

C’est un exercice très difficile de changer une telle habitude, vous devez vous-même être persuadé de l’intérêt pour l’équipe. Même si tout semble fonctionner correctement, tester le sevrage peut faire ressortir de bonnes choses.

Si cela ne change rien, et bien vous aurez fait gagner 15 minutes sur l’emploi du temps du PO.

Déjà dans un précédent billet, je m’étais attaqué à une autre dérive du PO : Quand le PO-technique dit comment faire. Ce rôle est délicat à cadrer car il n’existait pas vraiment, avant.

 

Et chez vous, aviez-vous déjà réfléchis à ça ? Le ou la PO est présent.e aux dailies, savez-vous pourquoi ? Pensez-vous pouvoir me convaincre que sa présence est bénéfique ?

N’hésitez pas à commenter pour donner votre avis.


Réagissez à cet article

J'aimerais vraiment connaître votre opinion à ce sujet. Ai-je manqué quelque chose ?

Si vous avez aimé cet article, je vous invite à le 📣 partager, à 👏 l’applaudir (pour qu’il soit visible à d’autres) et à visiter mon 👀 blog ou à me 🤙 contacter sur Twitter, LinkedIn ou Medium

Leave a Reply