Les Soft skills du Product Owner : kit de survie pour un rôle encore incompris
Et si l’un des secrets d’un bon Product Owner (PO) était de savoir dire non lorsque cela est nécessaire ? En tant que responsable du produit, sa position peut en effet paraître parfois inconfortable : il doit constamment faire des choix pour maximiser la valeur, arbitrer entre les attentes d'interlocuteurs tous convaincus individuellement de l’importance de leurs besoins.
Mais pour porter cette vision du produit il doit aussi créer de la cohésion, du consensus et permettre aux parties prenantes de travailler ensemble dans un esprit de co-responsabilité. Pour se tirer sereinement de ces situations complexes, il pourra s’appuyer sur certaines compétences qu’on n’apprend pas “by the book”... Éléments d'explication avec l'équipe qui anime la formation "Développer les soft skills du Product Owner" proposée par OCTO Academy (Charlotte Kerouredan, Sara Bianchi, Samy Amirou, Alban Baraffe).
Il existe un certain nombre d'idées reçues sur l'agilité, quelles sont celles que vous constatez le plus fréquemment ?
SA - Les principes de l’agilité sont assez anciens et, comme tout changement de paradigme l’impose, ils ont mis du temps à être compris, acceptés et appliqués dans les faits et à large échelle.
Il y a quelques années, l’Agile était très décrié car en rupture par rapport aux façons de faire classiques. Et, même si depuis quelque temps, on voit l’agilité se démocratiser et de plus en plus d’entreprises avoir de réels retours d’expérience sur la question, certaines idées reçues ont encore la peau dure.
D’une part, il arrive souvent que l’Agile soit associé à un manque de rigueur et d’engagement comparé aux méthodes de gestion de projet traditionnelles, vues comme plus sérieuses. L’idée reçue persiste que l’agilité incite à ne plus avoir de comptes à rendre et à considérer les retards comme acceptables. L’agilité est vue dans ces cas-là comme une doctrine inventée par les développeurs pour améliorer leur bien-être sans tenir compte des enjeux de l’entreprise.
On voit aussi beaucoup de personnes douter fortement de leur possibilité d’adopter une organisation agile car leur contexte serait incompatible : “nous ne sommes pas Google ou Spotify”, “notre organisation est trop grosse”, “l’Agile ça ne marche que sur le front”, “l’informatique n’est pas notre coeur de métier”.
Il s'agit manifestement d'une résistance aux changements qu'impose la passage à l'agilité. Cette transition est en effet très exigeante : elle ne demande pas seulement un changement de méthode et de pratiques ; elle repose aussi un changement de culture et un nouvel état d'esprit.
Ces dernières années, grâce à la vague du numérique, de nombreuses entreprises ont considéré qu’il s’agissait d’une question de survie, qu'il leur fallait changer leurs façons de faire pour évoluer vers des modèles d'organisation plus agiles qui depuis quelques années avaient commencé à faire leurs preuves. L’Agile est passé progressivement d’une pratique de niche à un réel effet de mode.
On constate néanmoins de grands quiproquos : beaucoup de structures, poussées par la popularité croissante de l’agilité et par les injonctions de leurs dirigeants, en ont adopté le vocabulaire pensant le comprendre, mais en gardant les anciens réflexes et en passant à côté de l’essence de la méthode.
En conséquence, on a pu voir apparaître de nouvelles idées reçues : “on peut changer de priorité du jour au lendemain”, “avec l’Agile, les développeurs vont plus vite”, "grâce à l’Agile on va diminuer drastiquement nos coûts".
Certains mécanismes inhérents à l’Agile sont encore trop “disruptifs” pour être appliqués. Le passage à l’agilité demande un relatif lâcher-prise sur la précision des prédictions et des délais sur le long terme. Il nécessite d’accepter qu’il existe une part non négligeable d'incertitudes et d’aléas et de les mettre au centre des préoccupations.
Parmi ces mécanismes, on distingue : prioriser et accepter de ne pas avoir tout tout de suite, accepter de découper en petits sujets (on a toujours découpé en lots mais c’est encore trop gros) et de ne livrer que de petites parties incomplètes.
Les logiques de confiance et de transparence (le fameux “les personnes et les interactions” du manifeste) peinent également à se mettre en place dans un monde qui fonctionne encore majoritairement dans une logique client / fournisseur, par contrats et prestations.
Les idées reçues sur l’Agile peuvent aussi provenir des équipes agiles elles-mêmes. Certaines approches de l’agilité peuvent parfois manquer de réalisme, si elles sont appliquées à la lettre. Par exemple : voir une équipe agile comme une entité 100% autonome, notamment sur les priorités ou dans ses relations avec les autres équipes. Ces approches de l'agilité peuvent devenir des prétextes pour faire abstraction des contraintes du terrain et des exigences du leadership. Il s’agit au final d’une autre façon de prendre l’Agile pour ce qu’il n’est pas.
Pensez-vous que le rôle de PO a évolué au cours des dernières années ?
AB - Le rôle de PO vient à l’origine du Scrum Guide qui lui donne la responsabilité de “maximiser la valeur du produit” réalisé par l’équipe de développement. C’est une responsabilité qui demande comme prérequis d’avoir une relative autonomie accordée par le management, notamment pour porter la vision produit et prioriser les fonctionnalités à développer.
Nous avons pu constater que la plupart des entreprises (à l’exception des start-ups) qui souhaitaient “passer à l’Agile” ont créé des postes intitulés “Product Owner” mais en leur attribuant les fonctions des rôles traditionnels de “Chef de projet” et MOA. Le bénéfice principal a été de réduire le fossé historique entre MOA et MOE.
Pour autant, dans ces schémas-là, le PO ne priorise pas vraiment : il s’assure que la priorisation est respectée, cette dernière étant décidée par les parties prenantes métier. Dans ces cas-là, ce n’est pas non plus le PO qui porte le besoin des utilisateurs ou qui est la principale force de proposition en termes de nouvelles fonctionnalités. Il est relégué à un rôle de responsable de la traduction des besoins en langage fonctionnel compréhensible par les développeurs.
Nous sommes encore loin du niveau d’autonomie suggéré par le Scrum Guide.
Avec le temps, nous avons toutefois constaté que le rôle de PO avait évolué et pris de plus en plus de légitimité et d’autonomie sur son produit. Le PO participe de plus en plus à la phase de “discovery” : il se rapproche des utilisateurs sur le terrain, étudie les mesures de leur utilisation du produit, en déduit des propositions d’amélioration. Les organisations accordent également une capacité dédiée à l’équipe pour être autonome sur de l’amélioration de produit.
Aujourd’hui, certaines approches comme les OKR (objectives and key results, objectifs collectifs basés sur des mesures business) permettent de tendre vers un modèle d’évaluation par le PO et son équipe, en se focalisant sur leur capacité à apporter de la valeur au travers du produit réalisé plutôt que sur leur aptitude à livrer des fonctionnalités dans le respect de deadline imposées.
Comment positionner le PO dans son écosystème aujourd’hui ?
CK - Le PO est le point focal de son écosystème. Il fait partie intégrante de l’équipe de développement et porte la vision produit. Le PO doit être capable de comprendre les décisions et les challenges techniques auxquels font face les développeurs. Dans le même temps, il assure la liaison entre le métier, le design et l’équipe de développement. Peuvent s’ajouter à ce triptyque d’autres interlocuteurs tels que le support utilisateurs, les commerciaux, les prestataires…
Ce positionnement central peut lui créer des difficultés :
Le PO est, en quelque sorte, au carrefour des préoccupations de tous. Il est, malgré lui, amené à participer à la résolution de beaucoup de problèmes. Ayant un rôle d’intermédiaire, il se retrouve souvent “entre le marteau et l’enclume”, par exemple, entre le besoin des parties prenantes métier pour que les fonctionnalités sortent vite et celui des développeurs qui est d’avoir suffisamment de temps pour intégrer les standards de qualité.
Comprendre suffisamment les choix techniques, mais aussi tous les enjeux utilisateurs, stratégiques et politiques de l’entreprise peut s’avérer complexe. Même s’il délègue, il doit malgré tout être suffisamment sur tous les fronts et peut perdre pied au milieu de ces sujets. Il doit composer avec les contraintes de toutes les équipes de l’écosystème produit.
Le PO porte également un rôle d’arbitre, qui n’est pas toujours facile : être au milieu de gens qui ne se parlent pas ou qui n’ont pas la même culture et/ou préoccupations est une situation délicate. Il peut arriver qu’il y ait un désaccord entre les développeurs et, bien que ce soit souvent en binôme avec le leader technique, le PO peut jouer un rôle de facilitateur pour qu’une décision soit prise.
Il doit également trouver un équilibre entre le build et le run. Une fois le produit en production, le PO doit participer activement à la maintenance de son produit en prenant en compte les retours utilisateurs et les bugs tout en faisant avancer sa roadmap.
Quelles qualités indispensables un PO doit-il pouvoir mobiliser pour réussir dans son rôle ?
SB - Les hard skills et l’expertise ne suffisent pas pour être un bon PO (ou de manière plus large, pour être agile). Un produit qui répond à la fois aux besoins des utilisateurs et à la stratégie business, ne peut pas résulter uniquement d’une vision d’expert sur un domaine ou sur une technologie. Toute la dimension des compétences comportementales, nécessaires pour adopter la bonne posture de PO, est trop souvent sous-estimée.
Le PO doit être curieux de l’environnement qui l’entoure et doit comprendre au maximum les adhérences entre chaque partie de l’écosystème. Il se doit de comprendre tous les enjeux de son produit, qu’ils soient techniques ou fonctionnels.
Le PO doit adopter une posture qui n’est pas facile : être le leader de son produit mais pas de son équipe. Le PO n’est pas un “chef”. Il doit faire en sorte que les développements avancent sans mettre la pression à l’équipe. Il doit veiller à transmettre le bon niveau d’informations et doit être transparent avec l’équipe tout en restant clair et synthétique pour ne pas les disperser. Il s’agit pour le PO d’être toujours dans le bon dosage.
Le PO va devoir, très souvent, jongler entre le métier et la technique : comprendre les besoins et les enjeux du métier et les traduire aux développeurs, tout en les priorisant, ou encore se faire challenger par les profils un peu techniques et aller trouver un compromis avec le métier. Ce n’est pas un exercice facile, loin de là. Cela nécessite de l’écoute active, une excellente capacité à communiquer, du bon sens et beaucoup de pragmatisme.
Le PO doit savoir comprendre les besoins stratégiques, déchiffrer les messages qu’il reçoit de toutes parts. Il va devoir reconnaître les opportunités qui apportent de la valeur et ensuite, les rendre intelligibles à d’autres personnes qui n’ont pas les mêmes préoccupations.
Le PO doit avoir d’excellentes capacités relationnelles : il doit être à l’aise pour communiquer avec l’équipe et pour rassurer le management qui lui demande des statuts d’avancement ou des explications sur des points de blocage.
Le PO n’est pas uniquement là pour gérer un backlog, suivre des KPIs ou rédiger des users stories. Il est là pour fédérer une équipe pluridisciplinaire autour d'une même vision. Son rôle s’apparente à celui d’un chef d’orchestre qui rassemble toutes ces personnes autour d’un objectif commun : faire le bon produit, au bon moment et de la meilleure façon possible.
Mais quelles sont ces soft skills qui feront de vous un bon PO ? Vous le découvrirez par la pratique lors de ces deux jours de formation. Des exercices, des mises en situation sans oublier ce qu’il faut de théorie sur les techniques de communication.
Vous animez une formation sur les soft skills du PO. A quelles conditions selon vous la formation sera-t-elle réussie pour les participants ?
Quelles sont ces soft skills qui feront de vous un bon PO ? Vous pourrez le découvrir par la pratique à travers la formation de deux jours que nous proposons avec des exercices, des mises en situation sans oublier ce qu’il faut de théorie sur les techniques de communication. Pour bien profiter de cette formation les participants devront néanmoins, à minima, connaître les bases de l’Agile et, plus particulièrement, les connaissances de base du métier de PO.
La formation permettra aux participants de gagner en sérénité et en confiance dans leur rôle de PO. A l’issue de cette formation, ils auront les clés de compréhension et des outils pour pouvoir sortir des situations compliquées qu’ils rencontrent au quotidien. Notre ambition : que les participants ressortent de la formation enthousiastes et avec une grande envie de mettre en pratique ce qu’ils auront appris.
**Plus d'info sur la formation :
"Développer les soft skills du Product Owner : adopter la bonne posture pour une communication impactante**" proposée par OCTO Academy (19 & 20 juillet, 18 & 19 novembre 2021).