Un Product Owner doit-il assister au Scrum quotidien ?

 

par Avi Schneier | J23 juillet 2021 | Blog

Le Product Owners doit-il assister au Daily Scrum ? Cette question m'est régulièrement posée.

Mettons donc officiellement un terme à cette affaire. 

Nous commencerons par examiner le Guide du Scrum, puis nous approfondirons la question par le biais d'une expérience pragmatique de la vie réelle. Enfin, nous terminerons par une analyse de la manière dont la présence des Product Owner peut détourner les Scrum quotidiens et comment faire de leur présence une expérience enrichissante.

 

Guide Scrum : Les règles du jeu

 

La version actualisée de 2020 Guide Scrum énonce clairement ce qui suit :

"Le Scrum quotidien est une épreuve de 15 minutes pour le Developers de l'équipe Scrum. Pour réduire la complexité, il a lieu à la même heure et au même endroit chaque jour ouvrable du Sprint. Si les Product Owner ou Scrum Master travaillent activement sur des éléments du Backlog du Sprint, ils participent en tant que Developers."

D'après cette phrase, ce n'est pas que le Product Owner devraient ou ne devraient pas participer - c'est qu'ils n'ont pas besoin de à moins, bien sûr, qu'ils ne soient en train de "tirer des arriérés" comme le Developers. Alors, si ces simples phrases sont si claires, pourquoi y a-t-il une confusion ou même une question sur leur présence ? 

Il s'avère que le guide Scrum peut nous donner plus d'informations qui nous conduiraient à la nécessité d'une assistance Product Owner.

Plus loin dans la même section, on peut lire

"Les Scrum quotidiens améliorent les communications, identifient les obstacles, favorisent une prise de décision rapide et, par conséquent, éliminent la nécessité d'organiser d'autres réunions".

La promotion d'une prise de décision rapide est une raison essentielle de détenir des Scrum journalières. 

Comme le révèlent les données du Chaos Report du Standish Group, la latence des décisions (le temps qu'il faut pour qu'une décision soit prise) est le facteur clé de la réussite d'un projet. Si ces décisions impliquent de modifier les priorités du carnet de commandes ou de donner la priorité aux interruptions plutôt qu'au travail du carnet de commandes du sprint, l'apport du Product Owner pourrait être considéré comme nécessaire au Scrum quotidien.

D'autres lignes du guide Scrum apportent des éclaircissements supplémentaires. Dans une partie antérieure, il est expliqué :

"L'équipe Scrum est responsable de toutes les activités liées au produit, qu'il s'agisse de la collaboration avec les parties prenantes, de la vérification, de la maintenance, de l'exploitation, de l'expérimentation, de la recherche et du développement ou de toute autre activité nécessaire.

et

"L'ensemble de l'équipe Scrum est responsable de la création d'un incrément précieux et utile à chaque sprint.

Ainsi, l'ensemble de ces éléments pourrait équivaloir à un argument rationnel expliquant pourquoi le Product Owner devrait être au Daily Scrum. 

Après tout, si toute l'équipe est responsable de l'incrément, si toute l'équipe est responsable de toutes les activités liées au produit et si la Product Owner fait partie de l'équipe Scrum - et non pas en est séparée -, alors elle devrait être à la Scrum quotidienne !

 

Parler des tranchées

 

Mettons maintenant de côté le guide Scrum et la théorie, et examinons ce que nous avons appris sur le terrain. J'ai interrogé un groupe de praticiens expérimentés du Scrum. Voici ce qu'ils m'ont dit :

"Le Product Owner appartient au Daily Scrum. L'absence d'une seule personne indique qu'elle ne fait PAS partie de l'équipe. Elle ne doit pas l'utiliser pour demander des mises à jour ou pour diriger la réunion de quelque manière que ce soit. Elle doit ECOUTER ce que l'équipe a à dire et PROPOSER une mise à jour de son côté. Si cet événement est utilisé pour imposer directement ou indirectement un sentiment d'importance ou de hiérarchie, il perd considérablement de sa valeur". - Toby Johnson, gestionnaire principal de produits

 

"Les rôles internes du Scrum devraient se dissiper temporairement pour créer un espace de sécurité psychologique, car le Scrum quotidien est une prise de pouls de "l'équipe". Bien qu'il ne s'agisse pas d'un événement destiné à apaiser les Product Owner ou à leur fournir une mise à jour de leur statut, ils pourraient y assister, mais en tant que membres de l'équipe et non en portant uniquement leur casquette de Product Owner". - Roy Nanku, ancien consultant NavalX Military Scrum Trainer et actuel consultant Scrum Inc.

 

"D'après mon expérience, le Product Owner doit être au Daily Scrum parce qu'il y a toujours des problèmes concernant des choses qui surgissent, tout autour de la priorisation du 'quoi'. " - Jessica Crowley, ancienne contrôleuse de projet pour un grand fabricant de freins de train et Enterprise Agile Coach, actuelle consultante Scrum Inc.

Il semble donc que nous disposions de données cohérentes sur la participation des Product Owners, mais que cela ne se fasse pas sans complications. Quels sont les principaux comportements de détournement dont font preuve les Product Owners ? Dressons-en la liste, puis examinons les solutions possibles.

 

Détourné ! (et se remettre sur les rails) 

 

Selon le guide Scrum, "Le but du Scrum quotidien est d'inspecter la progression vers l'objectif du Sprint et d'adapter le Backlog du Sprint si nécessaire, en ajustant le travail planifié à venir". Comprendre l'état d'avancement d'un travail et ce qui l'empêche d'avancer est un ingrédient essentiel pour ajuster le travail planifié à venir. 

Les coéquipiers qui s'entraident (parfois appelé "Swarming") est un modèle bénéfique que nous espérons voir coordonné lors de chaque Scrum quotidienne.

En fin de compte, tout est question de comportement. N'importe qui peut détourner ou faire dérailler le Scrum quotidien et le rendre improductif ou le dégrader en une simple réunion sur l'état d'avancement des travaux. S'il est important que tout le monde connaisse l'état d'avancement du travail, il est plus important encore de trouver des moyens, en tant qu'équipe, de faire en sorte que tout soit fait.

Quels sont les comportements Product Owner qui peuvent faire dérailler une Scrum quotidienne ? Et comment pouvons-nous les éviter ou y remédier ? Voici cinq catégories principales (avec des exemples) que nous voyons couramment et comment y remédier. 

1) Micro-gestionLe comportement le plus débilitant que nous observons est celui des Product Owners qui s'immiscent dans toutes les petites choses que font les Scrum Master ou les Developers. Un exemple de ce comportement est lorsqu'ils dictent le "comment" au lieu du "quoi" et qu'ils écrasent l'innovation. 

Un deuxième exemple est lorsqu'ils agissent comme des chefs de projet traditionnels et qu'ils assignent du travail à des personnes. Un troisième exemple est lorsqu'ils se concentrent excessivement sur les mesures de production de l'équipe, comme la vélocité, et qu'ils se demandent constamment pourquoi les éléments du carnet de commandes n'avancent pas.

Guérison : Restez en dehors du HOW ! Tout le monde sait que le Product Owner a son mot à dire, mais il vaut mieux laisser l'équipe vous éblouir par son génie. Au lieu de dicter comment les choses doivent être faites, parlez en dernier et posez des questions pour exposer les failles de la logique de manière positive ou pour pousser l'équipe à sortir des sentiers battus. C'est particulièrement difficile lorsque le Product Owner est aussi un Developer, il faut donc en tenir compte. N'assignez pas de travail au Developers. Laissez-les tirer ce qu'ils veulent faire et ce dont ils ont la capacité. La coordination est leur tâche, facilitée par le Scrum Master, et non par le Product Owner. Restez concentré sur les indicateurs de résultats et laissez l'équipe être guidée par les indicateurs de résultats (par exemple, la vélocité, le ratio plan/réalisation, etc.) La capacité de l'équipe à s'autogérer est importante pour créer une culture d'autonomie et de responsabilité.

 

2) Aimer les projecteurs: Il existe trois versions courantes de ce comportement. La première consiste à diriger la réunion. C'est l'expression d'une micro-gestion. Surtout si elle est dirigée de manière à obtenir les informations que le Product Owner souhaite, alors que le Developers obtient les informations dont il a besoin pour maximiser la probabilité d'atteindre l'objectif du sprint. Le deuxième est d'agir comme un public unique auquel les membres de l'équipe doivent présenter ce qu'ils ont fait. Le troisième est d'être perçu comme (et d'accepter le rôle de) l'unique source de réponses.

Guérison : Premièrement, ne facilitez pas le Daily Scrum. Sauf si c'est votre tour en vertu d'un accord de travail ou d'un autre arrangement. Laissez le Scrum Master aider l'équipe à déterminer qui doit le faire si ce n'est pas le Scrum Master lui-même. Deuxièmement, ne laissez pas le Developers s'adresser uniquement à vous. Encouragez-le à s'adresser au groupe ; faites-lui sentir que vous interviendrez si nécessaire. Cela inclut le langage corporel, c'est-à-dire qu'il ne doit pas vous faire face tout le temps. Troisièmement, veillez à ce que les membres de l'équipe ne vous considèrent pas comme une encyclopédie. Favorisez les conversations entre les membres de l'équipe en répondant par exemple : "Merci de m'avoir posé la question. Avant de répondre, j'aimerais connaître l'avis des autres membres de l'équipe."

 

3) Calendrier inapproprié pour les nouvelles demandes: Bien sûr, l'équipe doit être informée des nouvelles demandes, mais doit-elle l'être aujourd'hui ? Le fait de présenter de nouvelles demandes pour connaître les idées de l'équipe, juste pour les informer, etc. peut être très perturbant pour le travail en cours. Cela met leur cerveau en mode de résolution de problèmes pour les nouvelles choses et détourne leur attention de leurs engagements actuels. 

Guérison : Introduisez de nouvelles demandes au moment opportun. S'il s'agit d'une interruption vraiment importante, le Daily Scrum est parfait pour cela. Si ce n'est pas le cas, le meilleur moment pour les introduire est lors de l'affinage du carnet de commandes. En guise de plan de secours, il est possible de le faire dans le cadre d'une revue de sprint. Dans tous les cas, soyez judicieux dans le choix du moment où vous présentez de nouvelles demandes et réfléchissez à la manière dont cela affectera la concentration et les engagements de l'équipe. 

 

4) Retard ou sieste non annoncée: Les Product Owners passent beaucoup de temps avec les clients et les parties prenantes, souvent au détriment du temps passé avec leur équipe. Ils peuvent ainsi avoir l'impression d'être négligés ou que leur appartenance à l'équipe Scrum est moins importante que le reste du monde.

Guérison : Attendez-vous à agir comme n'importe quel autre membre de l'équipe et à arriver à l'heure. Si tu ne peux pas venir, respecte l'accord de travail que ton équipe a conclu concernant les retards ou le fait de se dire les uns aux autres que tu ne peux pas venir. L'équipe sait que tu ne seras pas présent à tous les Scrum quotidiens. Soyez conscient du nombre de fois où vous manquez ce rendez-vous et d'autres événements et voyez si les choses ne sont pas en train de se déséquilibrer. Faites en sorte de bloquer votre calendrier pour le Scrum quotidien (et d'autres événements) afin que vos coéquipiers sachent que le fait d'être avec eux est tout aussi prioritaire que le fait de parler avec ceux qu'ils servent.

 

5) Manque d'informations cruciales: Bien que nous encouragions les Product Owners à partager lorsqu'il y a lieu, cela peut également s'avérer perturbant lorsque les réponses que l'équipe recherche ne peuvent être obtenues parce que le Product Owner n'est pas au fait des besoins ou du retour d'information des clients.

Guérison : Si la présence de l'équipe est louable, le Product Owner doit néanmoins équilibrer le temps qu'il consacre aux clients et aux parties prenantes. Après tout, le but de ces interactions, et le rôle du Product Owner en général, est d'aider à traduire ces besoins et les informations qui les entourent en un carnet de commandes exploitable pour l'équipe. Sans cela, des obstacles peuvent être générés que l'équipe ne peut pas éliminer. Assurez-vous de participer à chaque revue de sprint et d'apprendre comment favoriser un bon retour d'information sur le produit et comment le capturer et le distiller dans un format digeste que l'équipe peut utiliser.

 

Conclusion

 

 

Le Product Owners doit-il assister au Daily Scrum ? Le Product Owners doit être présent au Daily Scrum car il est un membre de l'équipe qui a des informations cruciales à partager. Ils ne doivent pas oublier que leur présence peut être bénéfique ou préjudiciable et qu'il leur appartient d'adopter des comportements qui favorisent l'agilité de l'équipe et ne font pas dérailler les conversations nécessaires.