La relation entre le Product Owner, les Scrum Masters et les développeurs est essentielle à la réussite d’une équipe agile. Il s’agit d’une relation symbiotique qui repose sur une communication claire, des objectifs alignés, la transparence et qui est fondée sur la confiance. La création d’un produit largement adopté ou l’amélioration continue constituent généralement l’objectif, mais la cohésion et la dynamique de l’équipe peuvent déterminer à quel point ce processus se déroule sans heurts et sans difficultés.

Nous voulions en savoir plus, alors nous sommes partis à la recherche d’un Product Owner pour qu’il nous fasse part de ses réflexions et de ses expériences.

À la suite de sa présentation sur la feuille de route produit lors du Perth Agile MeetUp, nous avons rencontré Adam Mullett, auteur de l’ouvrage From “No” to “How?: Get Buy-in and Lead Change et Product Owner, afin de lui demander son avis sur le degré d’implication qu’un Product Owner devrait avoir lors d’une rétrospective.

Ce que nous avons obtenu n’était pas seulement une réponse à une question, mais une illustration du rôle du Product Owner et une prise de conscience renouvelée de l’importance de la confiance, de la transparence et de la discipline.

Les relations entre le Product Owner, les Scrum Masters et l’équipe agile

Adam a semblé quelque peu surpris lorsqu’on lui a demandé si un Product Owner devait participer à la rétrospective.

Cette question trouvait son origine dans le constat que certaines personnes impliquées dans l’agile considéraient la présence du Product Owner lors de la rétrospective comme facultative, voire comme un obstacle.

Après une brève hésitation, il répondit par un « oui ! » catégorique.

Il a ensuite expliqué « pourquoi » –

L’un des aspects importants de l’agile réside dans le fait qu’il ne s’agit pas d’être rapide, mais d’être capable de s’adapter, ce qui conduit à davantage de succès, comme une meilleure adoption d’un produit.

Lorsqu’il s’agit d’animer les rétrospectives d’une équipe, il est non seulement important de faciliter le processus, mais il est tout aussi important de veiller à la culture d’équipe. L’équipe s’appuie en effet fortement sur les orientations et les contributions du Product Owner, en tant qu’expert en la matière. Le Product Owner favorise un environnement dans lequel l’équipe peut s’efforcer d’être hautement performante, d’assumer la responsabilité des résultats et de s’autogérer, de manière à rester responsable vis-à-vis de ses parties prenantes.

Confiance et transparence

Adam estime que la confiance et la transparence sont des éléments essentiels du rôle de Product Owner.

« Pour moi, faire preuve de transparence est un atout, car cela permet de partager ses pensées ou ses connaissances. Si l’équipe ne parvient pas à vous faire parler, c’est que vous ne lui donnez pas ce dont elle a besoin pour réussir. »

« Il ne devrait y avoir aucun secret entre l’équipe, le Scrum Master et le Product Owner. Pour ma part, je me concentrerais sur ces points-là. Je préfère aborder le sujet et aller au fond du conflit plutôt que de laisser la situation s’envenimer. »

« C’est vraiment précieux de pouvoir identifier ce qui empêche une équipe d’avancer. »

Adam a donné l’exemple de deux membres d’une équipe avec laquelle il avait travaillé autrefois et qui ne se parlaient pas.

« C’était incompréhensible ! Ainsi, si un commentaire en rapport avec ce problème était formulé lors de la rétrospective, je continuais à creuser, à chercher à comprendre le « pourquoi », jusqu’à ce qu’ils se rendent compte que le problème venait de leur manque de communication. »

Même si cette approche s’est avérée quelque peu conflictuelle, une fois le problème mis en lumière, il a été plus facile de le résoudre, et les membres de l’équipe se sont par la suite réjouis que la situation ait été réglée.

« Pour résoudre ce genre de problèmes, il suffirait parfois simplement de proposer des horaires de travail différents. Le fait de ne pas se parler n’était tout simplement pas une raison valable pour ne pas former une équipe performante. »

Invitez les gens à participer à la conversation

Un Product Owner doit toujours garder à l’esprit l’importance de la collaboration ; c’est pourquoi Adam s’efforce de co-créer.

« Si je fais quelque chose, je veux le faire avec vous, pas à votre place. Aucun changement ne pourra jamais aboutir si vous le faites seul. »

« Étant donné que la collaboration au sein d’une équipe est indispensable à la co-création, il est important de savoir comment et quand impliquer les personnes concernées dans la discussion. Le choix de la manière dont ces discussions se déroulent peut faire toute la différence. »

« Par exemple, il est plus facile de montrer son travail à quelqu’un plutôt que d’essayer de le convaincre. Un prototype d’une heure avec lequel on peut dialoguer s’avère parfois bien plus efficace qu’une longue réunion de planification où l’on tente de vendre son idée. Dans d’autres cas, il peut être préférable de co-créer. »

Faites preuve de rigueur tant dans les méthodes que dans les résultats

Lorsque la discipline est considérée comme un pilier de soutien plutôt que comme un obstacle à la flexibilité, elle peut servir de levier pour renforcer l’autonomie de l’équipe.

La discipline peut se résumer à commencer une réunion à l’heure, à la terminer à l’heure et à avoir une définition stricte de ce que signifie « être prêt ». Il s’agit là de petits gestes convenus à l’avance que les membres de l’équipe respectent dans le but d’améliorer consciemment la cohésion et le respect au sein de l’équipe.

Selon Adam, c’est grâce à la discipline qu’il est possible de développer des habitudes saines qui favorisent l’efficacité des équipes.

« J’étais Product Owner dans un projet qui comptait 23 équipes et où l’état d’esprit général consistait à enchaîner les sprints les uns après les autres, en se contentant de les mener à bien tant bien que mal. »

« C’est alors que nous avons commencé à faire preuve de plus de discipline dans le sprint. »

« Oui, le premier mois a été difficile, car nous essayions de mener deux choses de front. Mais après cela, tout s’est bien passé. Et l’équipe a pu continuer à s’améliorer et à se développer pour devenir une équipe très performante. En fait, d’autres membres de l’organisation souhaitaient faire partie de cette équipe. »

On a également constaté que les équipes qui manquaient de discipline rencontraient des difficultés.

Que se passerait-il si les membres de l’équipe n’adoptaient pas une approche rigoureuse ?

« Si quelqu’un se présente sans s’être préparé, il est important de lui expliquer clairement l’objectif de la réunion et en quoi son comportement ne va pas dans ce sens. »

« Tout est une question de concentration. Lors d’une séance de grooming, par exemple, si les participants commencent à discuter d’un ticket en particulier, il s’agit alors de recentrer la discussion sur la raison d’être de cette réunion et sur l’objectif que nous souhaitons atteindre à l’issue de cette séance. »

Bien sûr, le Scrum Master veille au respect de cette discipline.

En ce qui concerne leur rétrospective, Adam a ajouté qu’une fois qu’une équipe comprend et apprécie la structure mise en place par sa discipline, elle est bien plus concentrée et efficace, sans avoir à recourir au « système 2 » de réflexion, tel que décrit dans l’ouvrage Penser vite, penser lentement de Daniel Kahneman.

« Disposer d’un processus clair facilite les choses. Les équipes ne veulent pas avoir à se soucier de détails tels que la salle ou la technologie qu’elles utilisent. Elles se concentrent sur le problème lui-même. »

Constituez votre équipe au fur et à mesure qu’elle élabore des solutions

En ce qui concerne Adam, il n’y a aucun doute quant au rôle du Product Owner : si vous êtes Product Owner, vous faites partie de l’équipe agile.

« Je pense que c’est au Product Owner, avec le soutien du Scrum Master, qu’il revient de développer la culture d’équipe et d’apporter de la clarté à l’équipe. »

« Les équipes détestent ne pas savoir où elles vont. Elles se retournent les unes contre les autres, elles s’agitent, elles essaient de donner l’impression d’être occupées, et toutes sortes d’autres dysfonctionnements apparaissent. Si vous pouvez donner aux gens une raison, un « pourquoi », une orientation stratégique, alors ils diront : « D’accord, super. C’est bon ! » Il s’agit donc d’être peu dépendants les uns des autres tout en restant étroitement alignés. De cette façon, nous savons tous où nous allons, puis nous permettons à l’équipe d’y parvenir. »

Adam a travaillé avec des équipes entièrement présentes sur place, à distance et hybrides. Pendant 18 mois, il a collaboré avec des collègues répartis de Sydney jusqu’en Inde. Quelle que soit la composition de l’équipe, l’un des facteurs de réussite d’une équipe hautement performante était la capacité à anticiper la suite des événements.

« Ainsi, si un problème surgissait lors de notre rétrospective, quelqu’un allait créer un ticket dans Jira. Les gens pouvaient continuer à travailler ensemble même s’ils n’étaient pas toujours dans la même pièce. Le fait de disposer de méthodes de travail bien rodées nous a permis de nous adapter à cette situation. »

Le rôle du Product Owner lors d’une rétrospective agile

Pour revenir à la question du rôle du Product Owner lors de la rétrospective, Adam a souligné que le Product Owner en est un participant.

Selon lui, la rétrospective peut être animée par n’importe quel membre de l’équipe ; il préfère toutefois que l’animation soit assurée à tour de rôle par les différents membres, afin que ces compétences puissent être développées et valorisées par l’équipe.

« Je pense que l’équipe souhaite que le PO fasse preuve d’honnêteté et d’ouverture d’esprit dans sa participation. »

Quant à ce qu’un Product Owner espère accomplir lors d’une rétrospective, la réponse d’Adam est simple : il s’agit de permettre à l’équipe de s’améliorer dans son travail.

Pourquoi ?

« En effet, le Product Owner est responsable des résultats vis-à-vis de l’organisation, qu’il s’agisse des délais ou des ressources utilisées. L’équipe, quant à elle, est chargée de produire ces résultats. Ainsi, un Product Owner avisé assistera à la rétrospective pour écouter. Il ne dira pas aux membres de l’équipe ce qu’ils doivent faire, ni qu’ils devraient le faire « de cette manière ». Si l’équipe le savait déjà, elle l’aurait fait. »

Adam considère cette rétrospective comme une occasion pour l’équipe de –

  1. découvrez des solutions
  2. apprendre au fur et à mesure afin de former une équipe hautement performante et
  3. pour gravir les échelons de maturité.

Le Product Owner souhaite contribuer à la constitution d’une équipe hautement performante pour de nombreuses raisons –

  1. afin d’améliorer la prévisibilité
  2. disposer d’une gestion des user stories efficace, rigoureuse et régulière
  3. afin d’améliorer la confiance et la qualité globales

à mesure que les fonctionnalités sont développées au fil du temps.

Encouragez et facilitez les changements lors de vos rétrospectives

Alors, pourquoi les rétros fonctionnent-elles ?

« Je pense que cela tient au fait que l’équipe a la possibilité de proposer des changements concrets. Elle peut définir des objectifs SMART qu’elle mettra en œuvre au cours des deux prochaines semaines. Ce sont les membres de l’équipe eux-mêmes qui identifient les problèmes qui les concernent, ce qui leur permet d’être les acteurs de ce changement. »

On a fait remarquer que certaines personnes peuvent craindre le changement parce qu’on leur impose quelque chose et qu’elles ont l’impression de ne pas avoir le contrôle.

« Dans mon ouvrage *De « non » à « comment ? », j’évoque notamment la sphère d’influence et les centres de contrôle. Il est important d’aider l’équipe à axer ses discussions sur les domaines où se situe son centre de contrôle, afin qu’elle se sente responsabilisée et capable d’apporter des changements. »

« Ils devraient avoir le sentiment de pouvoir compter sur le chef de projet pour tirer parti de son influence ou de son capital social afin d’exercer une influence au-delà de la sphère d’influence de l’équipe. »

« En attendant, si une équipe agile a le sentiment de maîtriser son destin, elle peut alors changer son environnement et faire bouger les choses. Elle se sent plus à même d’agir et peut ainsi aller de l’avant et mener à bien ses projets. »

Comment un Product Owner peut aider son équipe à éviter les dysfonctionnements

Nous ne pouvions pas laisser partir Adam sans lui demander conseil sur la manière de faire passer une équipe d’un état de dysfonctionnement à un niveau de haute performance.

Les points à retenir :

  1. Veillez à ce que chacun sache où il va, quel est son objectif, et assurez-vous que tout le monde est sur la même longueur d’onde.
  2. Veillez à ce que la communication soit fluide ; qu’il s’agisse des échanges entre les membres de l’équipe, entre le Product Owner et le Scrum Master, la communication doit être ouverte et honnête.
  3. De la discipline ! Offrez aux participants un cadre propice à la créativité. Commencez à l’heure et concentrez-vous sur l’objet de la réunion. Cela permet de mettre en place une structure qui favorise l’épanouissement de chacun.
  4. Expliquez-leur toujours pourquoi
  5. Signalez les dysfonctionnements. Le fait d’identifier les problèmes, les conflits et les erreurs est une bonne chose, car cela signifie qu’on a mis le doigt sur quelque chose.

Avez-vous d’autres idées ou anecdotes à partager sur la manière dont vous avez amélioré les relations de travail entre votre équipe Scrum et le Product Owner ? Nous serions ravis que vous les partagiez avec nous.

À propos d’Adam Mullett

De « non » à « comment » : susciter l’adhésion et mener le changement encourage le partage des résultats des tentatives d’amélioration qui ont échoué avec ses collègues et son supérieur, afin à la fois de bien assimiler la leçon et de faire profiter les autres de cet apprentissage.

Essayez une démo avec nos bots ludiques

ou

Commencez votre essai gratuit de 30 jours