On s'appelle ?

Product Owner et équipe : comment la collaboration peut impacter la performance ?

Agilité

 

Une collaboration efficace entre le Product Owner et l'équipe de réalisation est essentielle pour offrir un produit ou service à forte valeur ajoutée aux utilisateurs. Cette coopération est primordiale pour accroître la satisfaction client, ce qui contribue à stimuler l'activité commerciale et, par conséquent, le chiffre d'affaires.

À long terme, une bonne collaboration entre le PO et les experts de la fabrication améliore la performance de votre organisation.
Au cours de nos accompagnements, nous avons identifié plusieurs facteurs qui influent sur la qualité de cette collaboration. Ce sont ces derniers que nous vous proposons d'examiner dans les prochaines lignes.

Les pratiques qui rendent difficile la collaboration entre le PO et les équipes

Pour faire suite à l’article sur les rôles du Product Owner rédigé par Julie et Sarah, nous avons décidé de nous concentrer sur l’intégration et la posture du Product Owner au sein d’une équipe Agile dans le milieu du développement logiciel. Ces équipes évoluent toutes au sein d’une organisation qui apporte son lot de contraintes et d’héritages techniques et organisationnels qu’il est difficile de changer et auxquels elles doivent s'adapter.

Grâce à nos échanges internes et nos REX, nous avons identifié un ensemble de situations pouvant nuire à la collaboration entre le PO et les équipes avec lesquelles il travaille, en voici les plus fréquentes :

  • Le PO est rattaché à un service différent du reste de l’équipe. Cela engendre généralement un éloignement avec l’équipe de réalisation et peut nuire au sentiment d’unité de l’équipe Scrum. Cette distance organisationnelle impacte directement la fluidité de la communication.
  • Le PO, un ancien chef de projet qui n’arrive pas à sortir de son précédent rôle. S’il ne prend pas la mesure de la différence entre les 2 rôles et de l’évolution nécessaire pour mener à bien sa nouvelle mission, sa posture est alors biaisée et il a tendance alors à vouloir piloter le projet dans sa globalité. Il se peut alors qu’il ne se concentre plus sur sa mission première (recueillir les besoins et maximiser la valeur produite par ses priorisations) et adopte une attitude directive vis-à-vis de l’équipe. Cette posture engendre fréquemment des conflits entre le PO et les développeurs qui nuisent à l’efficacité de l’équipe.
  • La distance. Dans le contexte professionnel actuel, que ce soit dans les grandes entreprises ou dans les équipes de développement externalisées, la manière dont les membres d'une équipe sont organisés peut avoir un impact significatif sur leur efficacité. Deux défis majeurs se présentent souvent : la distance géographique et l'organisation en sous-équipes.
    La distance géographique peut se manifester de différentes manières, que ce soit à travers des équipes dispersées dans plusieurs villes ou des collaborations avec des prestataires externes situés à distance. Cette situation peut entraîner des difficultés de communication et des obstacles à l'établissement de relations de confiance solides entre le Product Owner et les développeurs. Les membres de l'équipe peuvent se sentir isolés et avoir du mal à partager efficacement les informations et les idées

Ces situations dégradent la collaboration entre PO et équipe de réalisation, avec pour conséquences probables :

  • Le remplacement du dialogue par de la communication purement écrite. La rédaction des « user stories » est une étape nécessaire pour transmettre les besoins des utilisateurs aux différents membres de l’équipe. Cependant, la communication écrite a ses limites et peut, lorsqu’elle est le seul moyen d’échange, entraver les partages d’expériences. Le manque d’échange verbal risque d’entraîner des difficultés de compréhension mutuelle, les discussions directes permettant de donner le contexte et de s’assurer de la bonne transmission des idées.
  • La mise en place d’une relation client / fournisseur. Ce cas est fréquent dans les situations mentionnées, où le PO est n’est pas considéré comme un membre de l’équipe mais comme un client qui exige un service de la part de experts techniques. Cette pratique amène son lot de problèmes au rang desquels :
    • Une perte de sens pour les développeurs car le contexte est absent
    • Le fait que chaque fonctionnalité puisse prendre plusieurs itérations à développer car ne répondant pas bien au besoin des utilisateurs
    • De la démotivation due au fait que le projet n’avance pas aussi vite qu’il le pourrait
    • Une solution technique et fonctionnelle uniquement pensée par le PO sans tirer parti de l’expertise des autres membres de l’équipe

Cette dynamique tue la collaboration au sein de l'équipe. Sur le long terme, elle a des conséquences sur la livraison d’un produit fonctionnel et donc potentiellement sur le business.


Chaque partie attend de l’autre d’être force de proposition. Un manque de communication et de confiance les uns envers les autres peut entraîner une telle situation.
L’instauration d’un climat de défiance ou le droit à l’erreur n’est plus possible entraine une spirale infernale ou l’innovation n’a plus sa place et l’insatisfaction est grandissante (pas de solution proposée -> mécontentement client -> perte de confiance de l’équipe -> pas de solution proposée...).

A tout problème, des solutions multiples

Dans tous les cas évoqués précédemment des solutions sont possibles et nous allons proposer ici nos approches d’accompagnement qui permettent d’éviter ces écueils, en gardant à l’esprit que chaque situation est différente et des adaptations sont :

  1. Le PO se trouve à distance, qu’à cela ne tienne de nombreux outils permettent aujourd’hui d’être actif et efficace dans une démarche collaborative (management visuel digitalisé, boards interactifs, appels Teams à plusieurs...). Ajouté aux outils de gestion du backlog qui permettent à chacun d’informer et d’être informé sur les taches en cours, les outils technologiques permettent aujourd’hui de se synchroniser en temps réel comme si l’on était situés dans un même bureau.
  2. Les user stories deviennent un facteur de motivation en donnant du contexte aux développeurs. Des US détaillant des cas d’usages réels, par exemple comme critères d’acceptation, permettent aux développeurs de comprendre les situations dans lesquels l’outil sera utilisé. Ils comprennent mieux les attentes et les besoins des utilisateurs, ce qui leur permet de concevoir des solutions plus adaptées.
    En donnant ainsi de la visibilité et du sens au travail effectué, le PO renforce l’engagement et la motivation des membres de l’équipe.
    En parallèle à cette démarche, prévoir des temps d’échanges réguliers avec le(s) client(s) est un facteur fondamental pour aligner tous les membres d’une équipe sur sa vision ses objectifs à atteindre.
  3. Le dialogue régulier est un ingrédient essentiel pour réussir la collaboration au sein d’une équipe. La communication directe a de nombreux avantages :
    • Rapidité de transmission des informations
    • Clarification de celles-ci et mieux se comprendre
    • Ouvrir le dialogue et permettre une pensée critique
    • Trouver de meilleures solutions
    • Développer et/ou renforcer la cohésion de l’équipe
  4. Multiplier les sessions de brainstorming collectif et de co-construction.  L’affinage des US est un moment privilégié pour que les membres d’une équipe réfléchissent ensemble aux solutions techniques qui répondent le mieux au besoin. Cela permet à la fois au PO de prendre du recul sur le besoin réel, là où les utilisateurs expriment parfois déjà des solutions, et au reste de l’équipe de décrire leurs idées pour comprendre si elles peuvent y répondre. Des sessions d’échange et de réflexion courtes mais régulières permettent de renforcer la collaboration et d’enrichir les solutions proposées bien plus que ne le ferait le travail individuel de chaque membre.

 

La complémentarité entre Product Owner et Developers/experts techniques, vecteur de performance

En raison de leurs parcours et de leurs expériences passées, le Product Owner et les responsables de la réalisation ont souvent des compétences très différentes :

  • Les Developers ont plutôt des compétences techniques, qui leur permettent de concevoir et fabriquer les produits
  • Le PO, lui, s’appuie sur ses compétences fonctionnelles et sa compréhension du besoin client pour mener le produit fourni à son plein potentiel

De ces compétences complémentaires peuvent donner naissance à des produits performants aussi bien pour l’utilisateur final que côté business pour l’entreprise. Pourtant, ce n’est pas ce que l’on observe dans toutes les équipes pour les raisons mentionnées ci-dessus et bien d’autres mais comme nous avons pu le voir, des solutions existent.

S’il ne fallait retenir qu’une idée de cet article, le maître-mot pour renforcer la cohésion et performance d’une équipe est la COMMUNICATION.

Vous aussi vous rencontrez des difficultés entre Product Owners et experts en développement logiciels au sein de votre entreprise ?

Vous souhaitez être accompagné par l’un de nos copilotes du changement ?

Article rédigé par

Vincent Gillet

Co-pilote du changement

Julie Augizeau

Co-pilote du changement