Product Owner – développeurs : Je t’aime moi non plus?

Product Owner – développeurs : Je t’aime moi non plus?

Dans le cadre de notre fonction de Product Owner ou de Product Manager, une partie non-négligeable de notre rôle pourrait se résumer en ces quelques mots : “Créer des liens”. Des liens entre les équipes marketing et les problématiques techniques, entre les équipes techniques et les contraintes métiers… Mais c’est avant tout établir des connexions entre des personnes : de divers services, de divers backgrounds. A commencer par les développeurs de notre propre équipe.

Dans la plupart des équipes dont j’ai fait partie ou que j’ai pu observer, l’état de la relation et la qualité de la communication entre PO et développeurs m’a toujours semblé être un excellent indicateur de la “santé” de l’équipe. On ne peut que déplorer les cas, où les développeurs ont l’impression de subir les choix du PO, et ceux où un PO se sent prisonnier d’une équipe de développeurs remettant en cause tous ses choix.

Un PO, des développeurs, une seule équipe

Il ne faut jamais oublier que le Product Owner est un membre de l’équipe à part entière et à ce titre les difficultés techniques auxquelles font face les développeurs sont ses difficultés, et le PO se doit d’être compréhensif et actif dans la résolution de ces problèmes (voir l’article d’Antoine à ce sujet ici).

Parler la même langue

Le langage est aussi un élément important, même sans avoir de background technique, il est important qu’un PO soit en mesure de suivre dans les grandes lignes un débat technique entre les devs de son équipe. La compréhension et l’utilisation du vocabulaire technique approprié fera sentir à vos coéquipiers que vous montrez de l’intérêt pour leurs problématiques techniques. Dans la mesure de ses connaissances techniques, il est important pour un PO de manifester une réelle curiosité pour l’environnement technologique des développeurs afin de démontrer son implication au reste de l’équipe.

Rassembler l’équipe

Pour souder l’équipe, il ne faut pas négliger aussi le fait de savourer ensemble les réussites. Toujours dans l’esprit “d’établir des liens”, une des fonctions du Product Owner dans l’équipe est aussi de faire partager à l’équipe les compliments et remarques positives (ou négatives) qu’il est susceptible de recevoir des stakeholders ou de tout autre personne sur la qualité du produit, la vélocité de la mise en production d’une fonctionnalité… Ces feedbacks doivent être transmis à l’équipe systématiquement et le plus rapidement possible, il est très important pour le PO de faire en sorte que toute son équipe soit sur un même niveau d’information. Ces petits mots peuvent paraître anodins mais c’est cela qui permet à l’équipe de se rassembler autour d’objectifs et d’avancer ensemble. Un déjeuner ou une petite sortie d’équipe de temps à autre est aussi tout à fait indiqué. 🙂

S’appuyer sur l’équipe pour concevoir

Dans une équipe où l’on partage les bons et les mauvais moments, de l’empathie mutuelle va se créer, les développeurs seront alors vos meilleurs alliés dans la réflexion autour de votre produit. Communiquer avec les développeurs sur vos stories à venir de manière fluide et en amont des cérémonies “officielles” pourra vous permettre de faire émerger une problématique ou une incohérence dans une de vos user-stories. Ces discussions avant le grooming ou la planification pourront ainsi vous faire gagner un temps précieux.

De plus, il ne faut jamais négliger la plue-value fonctionnelle que peut vous amener une bonne communication avec les développeurs. Ils sont immergés dans le produit à longueur de journée, au moins autant que vous, et sont donc à même d’apporter des réflexions constructives sur l’évolution du produit. Lors des groomings ou lors des discussions plus “off”, je n’hésite jamais à demander l’avis de l’équipe sur une feature, un design, ou à leur exposer mes doutes, cela donne très souvent lieu à des réflexions très constructives et la fonctionnalité en ressort plus aboutie.

Ces discussions ont aussi pour effet bénéfique de générer une sensibilité pour le produit de la part de l’ensemble de l’équipe, mais c’est aussi une marque de confiance du PO envers son équipe que d’aborder ce genre de sujet avec les développeurs.

Établir une relation de confiance

Vous devez avoir confiance en vos coéquipiers tout comme ils doivent avoir confiance en vous. Votre priorisation et votre vision seront alors beaucoup mieux comprises et acceptées.

Ne pas isoler l’équipe des réalités

Tout comme les développeurs se doivent de communiquer sur les contraintes techniques qui peuvent vous impacter (remboursement de la dette technique, installation d’un nouvel outil…), il est essentiel que vos coéquipiers développeurs aient conscience de vos contraintes fonctionnelles (deadlines, interlocuteurs…), ce sont autant d’informations qui aideront l’équipe à comprendre vos choix, vos priorisations.

De plus, il est très important de ne pas isoler l’équipe du “monde réel”, les développeurs ne travaillent pas pour vous, ils travaillent pour un produit, pour des utilisateurs. Il est donc essentiel que le PO/PM le fasse ressentir à son équipe en donnant toujours du contexte métier, marketing, utilisateur aux développements priorisés. Il est aussi bon, dans la mesure du possible, de créer des interactions directes entre les développeurs et les différentes parties prenantes du produit voire même les utilisateurs.

Pour ma part, j’invite dès que possible aux séances de backlog-grooming des personnes extérieures à l’équipe (quelqu’un du marketing, de la web analyse, des équipes infra…) si cette personne peut apporter du contexte et des informations pertinentes sur les sujets discutés en séance.

Emmener l’équipe avec soi

La confiance que vous porteront vos développeurs sera aussi fortement liée à votre capacité à rester rigoureux et stable dans la gestion de votre produit. Les développeurs sauront accepter vos choix s’ils savent que ce sont les vôtres, qu’ils sont justifiés et fruits d’une réelle réflexion. Il est compliqué de demander à une équipe de suivre un PO sur un chemin qu’il ne maîtrise pas où il n’a pas toutes les cartes en main et où la direction change à chaque nouveau sprint de développement.

Cet élément est aussi à mettre en lien avec la protection de l’équipe qui est une des fonctions du PO. Un PO “influençable” et n’avançant pas sur une stratégie claire aura tendance à accepter trop de demandes parasites, ou à changer de priorisation trop souvent, ce qui peut avoir pour effet de le décrédibiliser auprès de l’équipe.

Vous devez montrer aux développeurs que vous avancez sur une voie claire et cohérente, cela passe par de la communication, de l’organisation, avoir un backlog clair, commencer à aborder les sujets avec l’équipe le plus tôt possible…

Un leader, mais pas un chef

A aucun moment le PO n’est le chef des développeurs, c’est ce qui rend le challenge d’arriver à fédérer une équipe autour d’une vision d’autant plus difficile et intéressant. Le bon PO/PM devrait chercher à être un leader et par définition, à convaincre par d’autres moyens que celui de la classique hiérarchie. Sa vision doit être claire, partagée mais aussi challengeable, et c’est ce point qui en fera quelque chose qui n’est pas imposé et que chacun peut s’approprier. Le PO doit avoir la détermination de mener à bien sa stratégie mais doit aussi avoir l’écoute nécessaire pour prendre en compte toutes les remarques afin d’intégrer celles qu’il jugera pertinentes.

Il doit être à la base d’une réelle collaboration avec les développeurs où chacun apporte ses compétences au service d’un objectif commun. Aucun membre de l’équipe n’obéit aux ordres d’un autre, mais chacun doit tâcher de mettre son expertise au service du produit. Et c’est en communiquant et en écoutant ses coéquipiers que le PO arrivera à libérer la force de proposition de chacun d’entre eux. C’est en étant à la fois le rassembleur et le porteur d’objectifs co-construits par l’équipe que le PO/PM peut s’imposer comme un leader.

En conclusion

Le mot d’ordre de cette relation développeur-PO est donc la confiance, mais aussi le partage : des difficultés, des objectifs… Votre roadmap et vos contraintes produits ne doivent avoir aucun secret pour les développeurs, et il est important que les développeurs souscrivent à la vision produit, dont vous êtes le garant mais que chacun doit s’approprier.

Pour arriver à cela, l’implication des développeurs dans l’établissement de la roadmap produit est crucial, en terme d’estimation de la charge, de faisabilité, d’ordonnancement et aussi tout simplement en terme de cohérence produit. Par exemple dans le cadre d’un atelier de co-création de roadmap “Buy A Feature” (voir comment l’organiser ici), il est assez aisé de faire participer l’équipe aussi bien dans la préparation de l’atelier que dans l’atelier en lui-même afin que les développeurs aient un réel rôle dans la construction de la roadmap.

Au delà du travail opérationnel lié au produit, la fonction de Product Owner/Product Manager impose aussi de faire face à un challenge humain. De part sa position centrale, il doit convaincre sans imposer, être à l’écoute tout en gardant ses convictions…

C’est un des principes même de l’agilité de mettre l’humain au centre des processus et il est donc fort logique que cette composante relationnelle ait une grande importance dans le quotidien du Product Owner. Négliger cet aspect de la fonction reviendrait à ne pas exploiter le plein potentiel de son équipe, et ainsi se priver d’une force de frappe supplémentaire dans l’amélioration de votre produit.

2 Comments Product Owner – développeurs : Je t’aime moi non plus?

    1. Clément Liard

      Bonjour Guillaume,
      Tout d’abord, merci pour votre commentaire!
      Concernant le premier point, oui j’entendais vélocité au sens « classique » du terme (=rapidité), il est vrai que ce mot est très connoté dans le milieu des équipes Scrum
      Pour votre deuxième remarque, j’utilise en effet le mot « grooming » ou « backlog-grooming » mais je n’étais pas au courant de ce fâcheux double-sens possible…
      Merci pour votre retour,
      Clément

      Reply

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *