#9. Adoptez la bonne posture
Le métier de Product Owner, c’est aussi jongler et faire le grand écart en même temps !
D’une manière générale, les Product Owners embrassent les valeurs de l’agilité, dont la collaboration et l’entraide. Ils n’ont pas de lien hiérarchique avec les développeurs, et sont des membres de l’équipe à part entière plutôt que les « chefs » des équipes de développement. À ce titre, ils doivent adopter une posture toute particulière que nous nous allons détailler ici même.
Les qualités du Product Owner
il sait parler à des commerciaux, des équipes marketing, des équipes techniques et… des experts métiers.
Il est polyglotte
Le Product Owner est au carrefour des univers métier et technique. Il doit donc porter son attention dans ces deux directions à la fois. Une des principales qualités d’un Product Owner est d’être polyglotte : il sait parler à des commerciaux, des équipes marketing, des équipes techniques et… des experts métiers.
Il doit être capable de transmettre et véhiculer des informations, à tout moment, en adaptant son discours à son interlocuteur. Ainsi, il est en mesure de répondre aux questions métier que peut se poser l’équipe de développement, et à l’inverse de pouvoir fournir des points d’avancement ou des alertes aux métiers sur les réalisations en cours, sans rentrer dans les considérations techniques.
Il aime communiquer, communiquer et communiquer
Cette qualité nous semble un pré-requis à la réussite de la mission principale du Product Owner à savoir « porter » la vision produit auprès des membres de l’équipe. Le Product Owner explique la valeur métier du besoin, et pas seulement le « quoi », afin que les développeurs puissent se l’approprier.
Il est curieux et un peu geek
Sans demander au Product Owner de réellement développer le produit, il se doit d’être curieux et de savoir comment est construit son produit (ex : Quelles API sont utilisées pour livrer cette fonctionnalité ?). Le Product Owner doit être en mesure d’expliquer aux métiers les compromis et les décisions techniques prises par l’équipe de développement. Il est autonome sur les outils et les petites tâches techniques. Il est très agréable pour une équipe de développement de ne pas être sollicitée par un Product Owner qui vient la voir tous les jours pour lui demander de lui changer son mot de passe, de manipuler tel ou tel jeu de données ou pour lui demander pour la n-ème fois l’URL de la plate-forme de pré-production.
Comme un bon scout, il est toujours prêt !
Le Product Owner a conscience que le développement produit n’est pas un processus gravé dans le marbre et nécessite en permanence des ajustements. Il travaille donc en collaboration avec l’équipe lorsque des changements doivent être faits ou que des obstacles sont rencontrés. En ce sens, il est « agile » car il sait adapter son backlog en fonction des circonstances. L’équipe accordera plus facilement sa confiance à un Product Owner si elle sent qu’il peut s’adapter rapidement et qu’il est capable de proposer des alternatives.
Et pour finir, il est fun !
Un Product Owner positif et amusant peut apporter une grande contribution au moral de l’équipe. Vous serez forcément confronté à des périodes difficiles et dans ces moments là, une dose d’humour peut grandement aider à passer ce cap. Surtout, soyez humble et donnez à l’équipe de développement le crédit qu’elle mérite !
L’attitude vis-à-vis de l’équipe de développement
Comme membre de l’équipe, vous participez à toutes les cérémonies.
Au sein de l’équipe, même si les rôles sont importants, en tant que Product Owner vous ne devez pas être mis sur un piédestal. Vous devez montrer que vous êtes un membre à part entière de l’équipe et que vous êtes convaincu par l’approche itérative et incrémentale.
Comme membre de l’équipe, vous participez à toutes les cérémonies. Que vous soyez en Scrum ou au sein d’un système Kanban, vous êtes concerné par le planning poker, le sprint planning ou la simple présentation d’un lot de user stories prêtes à être développées, le point quotidien, la démonstration, les rétrospectives ou les ateliers de résolution de problèmes ou d’amélioration continue.
Le point quotidien
Participer au point quotidien vous permet de communiquer sur votre activité de la même manière que tout équipier. Ainsi, les développeurs auront de la visibilité sur les prochaines user stories sur lesquelles ils vont très prochainement travailler et se rendront également compte que parfois, alimenter un backlog de manière pertinente n’est pas un long fleuve tranquille.
La présentation des user stories
Il semble naturel que le Product Owner participe à la présentation des user stories, puisque celles-ci doivent inviter à la conversation entre tous les membres de l’équipe. Cependant, l’apport du Product Owner ne doit pas se limiter à répondre aux questions des développeurs sur ses user stories ; en étant attentif aux conversations techniques qui alimentent le planning poker, le Product Owner peut déceler des signaux faibles concernant le travail à faire : telle story entraîne un travail de conception collaboratif, telle autre semble triviale ou encore le feedback des équipiers ouvre des perspectives inédites pour de future stories…
La rétrospective
Certains Scrum Masters peuvent “interdire” l’accès à la rétrospective au Product Owner (si, si, c’est arrivé). Cet anti-pattern est bien souvent un mauvais signal. Aucune équipe agile avancée ne se tire une telle balle dans le pied : le Product Owner doit pouvoir tout entendre et tout dire. Il doit pouvoir remonter un dysfonctionnement qu’il a constaté mais également être prêt à entendre que sa manière de travailler est remise en cause.
En participant activement à toutes ces cérémonies, le Product Owner sera en mesure de remplir correctement son rôle en étant le garant du développement du bon produit, en assurant la bonne visibilité de l’avancement vis-à-vis des parties prenantes et en étant un acteur de l’amélioration continue de l’équipe.
Enfin, la résolution de problèmes est un sport collectif. Toutes les idées sont bonnes à prendre, et embarquer une personne qui n’est pas forcément technique est une marque d’ouverture d’esprit !
L’attitude vis-à-vis des parties prenantes
Donner une visibilité globale
Si vous travaillez dans une approche Kanban, vous avez rendu les étapes de maturation des user stories visibles. Même en Scrum, un management visuel de cette progression est de plus en plus adopté et a de nombreux avantages : le board renforce la cohésion de l’équipe et permet surtout au Product Owner d’organiser son travail, de planifier ses ateliers et de s’assurer que l’équipe de développement sera bien alimentée en user stories qui satisfont la Definition of Ready.
Savoir dire non
Nous ne pouvons pas clore cette règle sans parler de la posture du Product Owner vis-à-vis de ses métiers ou de son management. Si le Scrum Master se pose parfois en gardien de l’équipe, le Product Owner doit se poser en « gardien » du produit. Non, tout n’est pas pour tout de suite. Non, telle fonctionnalité n’a pas forcément sa place dans cette version, voire dans le produit. Non, il n’y aura pas de miracle et la date d’atterrissage ne va pas magiquement avancer. Ce rôle est difficile à tenir. Il faut, diplomatiquement, parfois porter des discours que vos métiers ou votre management n’ont pas envie d’entendre. Cela fait aussi partie des lourdes responsabilités du Product Owner.
Cet article a originalement été publié dans notre Product Academy. Si vous voulez un compagnon physique demandez votre exemplaire sur notre site !
Et si vous avez aimé cet article, n’hésitez pas à nous donner un petit coeur !
