Le Daily Scrum soulève régulièrement une question en apparence simple: le Product Owner (PO), responsable de maximiser la valeur du produit, doit-il y assister? Le Scrum Guide a posé un cadre depuis 2020, mais la pratique reste souvent confuse dans les organisations.
Ce que dit le Scrum Guide
Le Scrum Guide 2020 a simplifié la formulation: le Daily Scrum est un événement pour les Developers. Ce sont eux qui décident de sa structure et de son contenu. D’autres personnes peuvent y assister, à condition de ne pas perturber l’événement. Le Product Owner n’est donc ni interdit ni obligé d’y participer.
Cette formulation représente un assouplissement par rapport aux versions précédentes. Le Guide 2017 réservait explicitement le Daily à l’équipe de développement, avec le Scrum Master comme gardien du format. La version actuelle fait confiance aux Developers pour gérer leur propre synchronisation.
Pourquoi la question persiste
Si le cadre est posé, la question persiste parce que la théorie et la pratique divergent souvent. Dans de nombreuses organisations, le Product Owner est le principal interlocuteur entre l’équipe et les parties prenantes. Son absence du Daily peut créer un décalage d’information, tandis que sa présence peut modifier la dynamique des échanges.
Le vrai enjeu n’est pas la présence physique du PO, mais son comportement pendant la réunion. Un Product Owner qui écoute et prend des notes pour mieux débloquer l’équipe ensuite apporte de la valeur concrète: il peut répondre immédiatement à une question de priorisation ou relayer un obstacle au sponsor dans l’heure. Un Product Owner qui transforme le Daily en session de reporting ou qui challenge les estimations crée un problème, car l’équipe cesse de partager ses vraies difficultés.
Les signaux d’alerte
Plusieurs indicateurs suggèrent que la présence du PO au Daily pose problème. Le premier est l’autocensure: si les Developers cessent de mentionner les difficultés ou les retards lorsque le PO est présent, la réunion perd sa fonction de synchronisation. Le deuxième est la dérive temporelle, car un Daily qui dépasse systématiquement les quinze minutes quand le PO y assiste indique que des discussions qui n’ont pas leur place dans cet événement s’y glissent.
Le troisième signal est le plus subtil: le changement de ton. Quand le Daily passe d’une coordination entre pairs à un compte-rendu hiérarchique, le format est compromis. Les Developers ne se parlent plus entre eux, ils s’adressent au PO. Ce glissement est parfois difficile à détecter de l’intérieur, ce qui donne au Scrum Master un rôle d’observateur particulièrement important.
Les conditions de succès
La participation du PO au Daily fonctionne bien dans certaines configurations. En début de sprint, quand les questions de priorisation sont fréquentes, sa présence permet de trancher rapidement sans attendre une réunion séparée. Dans les équipes matures, où la confiance est établie, le PO participe naturellement sans que personne ne le perçoive comme un superviseur.
Les équipes distribuées tirent aussi un bénéfice particulier de la présence du PO au Daily, car cet événement est parfois le seul moment synchrone de la journée où l’ensemble de la Scrum Team peut échanger.
La maturité de l’équipe reste le facteur déterminant. Une équipe qui débute en Scrum a besoin d’un espace protégé pour apprendre à se synchroniser sans pression externe. Une équipe expérimentée sait gérer la présence de n’importe quel observateur sans modifier son comportement.
Comment décider
La décision la plus pragmatique consiste à commencer par inviter le PO, puis à évaluer l’impact après quelques sprints. Le Scrum Master joue ici un rôle d’observateur: c’est lui qui peut identifier les changements de dynamique que l’équipe ne perçoit pas toujours elle-même.
Si des tensions apparaissent, la rétrospective est le bon endroit pour en discuter ouvertement. La question “le PO devrait-il continuer à assister au Daily?” mérite d’être posée périodiquement, pas tranchée une fois pour toutes. Les équipes évoluent, les projets changent et ce qui fonctionnait en début de collaboration peut devenir contre-productif six mois plus tard.
Mike Cohn, cofondateur de la Scrum Alliance, recommande d’ailleurs cette approche empirique: tester, observer, ajuster. C’est le principe fondamental de Scrum appliqué à ses propres pratiques.