Le rôle de Product Owner dans LeSS est conceptuellement le même que celui dans une unique équipe Scrum. Toutefois, à grande échelle la focale change légèrement pour aller vers quelque chose permettant de garder une vision globale et de garantir un retour sur investissement (ROI) maximum au niveau du produit.

Le Product Owner à grande échelle

S’il est une chose assez répandue dans le développement de produit à grande échelle c’est que différentes personnes tirent dans différentes directions et pour des sous-groupes de se focaliser sur des sur-optimisations au niveau local. Avoir un seul Product Owner avec un seul Backlog de Produit permet de maintenir un focus sur le produit global (fr).

Dans les traditionnels groupes produit à grande échelle, nous trouvons d’une part un groupe (souvent des responsables produits - product managers -) focalisé vers l’extérieur et d’autre part un groupe (généralement les développeurs) focalisé vers l’intérieur - et jamais aucun des deux ne se rejoignent. Dans LeSS, le Product Owner unique dispose de beaucoup de temps pour se focaliser vers l’extérieur - les clients et leurs priorités - tout en étant aussi en capacité de prendre du temps pour se focaliser vers l’intérieur - les équipes. Il agit en tant que connecteur, faisant se réunir ensemble les équipes et les clients/utilisateurs afin que les équipes deviennent encore plus [orientées clients (fr)]https://less.works/less/principles/customer-centric.html).

Par rapport à d’autres approches de Scrum à grande échelle, il est possible avec LeSS de passer à grande échelle le rôle de Product Owner avec une seule personne parce qu’il y a moins de rôles, de positions et moins de complexité.

Priorisation plus que Clarification

Il y a deux flux d’informations-clés dans Scrum qui sont liés au Product Owner : (1) la priorisation (ordonnancement) des éléments dans le Backlog de Produit et (2) la clarification des éléments dans le Backlog de Produit. Dans le premier flux (priorisation), les informations liées aux centres de profits, aux clients stratégiques, aux risques métiers, et à d’autres préoccupations métiers sont recherchées et analysées. Dans le second flux (clarification), l’information est recherchée pour détailler le comportement et les qualités intrinsèques des éléments, l’expérience utilisateur, et à d’autres préoccupations sur la conception des fonctionnalités.

Un Product Owner LeSS porte une réflexion accrue sur la priorisation mais collabore avec les équipes sur la clarification. De plus, il encourage et aide les équipes à entrer en communication directe avec les véritables utilisateurs et clients pour plus de clarification. Il agit en tant que connecteur, pas en tant qu’intermédiaire.

Pourquoi mettre l’emphase sur une interaction directe entre les équipes et les clients/utilisateurs ? Voici quelques raisons : (1) éviter la perte d’informations liée au passage de relais, (2) encourager la co-création de solutions aux problèmes réels des clients, et (3) améliorer la motivation et l’empathie envers les clients en ayant des développeurs qui collaborent directement avec eux.

Il est important de noter que lorsque les équipes font le gros du boulot de clarification, le Product Owner dispose de plus de temps et d’énergie pour se focaliser sur la vision globale, pour prioriser de manière continue et pour explorer de nouvelles opportunités stratégiques.

Trouver un Product Owner en fonction de votre type de développement

Étape 1 : connaître votre type de développement

Trouver le bon type de Product Owner dépend de la connaissance de votre type de développement :

  • Développement de produits pour des clients externes ou un marché
  • Développement (de produit) à usage interne pour un ou plusieurs utilisateurs à l’intérieur de l’entreprise. Un tel groupe de développement s’appelle généralement Développement des Systèmes d’Informations ou l’Informatique
  • Développement d’un projet généralement pour un client externe. Le travail est organisé et contractualisé sous la forme d’un projet quel qu’il soit bien que cela ne signifie pas pour autant un contrat du projet basé sur le triangle périmètre/date/coût. La société de développement est généralement un prestataire extérieur ou un intégrateur-système. Le client, ou l’entreprise cliente, englobe à la fois l’entité acheteuse et les utilisateurs, qui ne sont pas nécessairement dans le même département.

Étape 2 : trouver le bon Product Owner

Développement de produits - l’entreprise aura soit (1) une unité métier pilotant l’initiative produit (exemple : la banque de détails), ou (2) un département de gestion produits pilotant l’initiative. Traditionnellement, la gestion de produits est responsable de l’analyse des clients et de la concurrence, de la vision produit, de la sélection et de la priorisation des fonctionnalités à grosse maille, de la feuille de route produit, ainsi que d’autres activités non techniques. On ne gère pas non plus le travail d’un groupe de développement traditionnel.

Où donc trouver un Product Owner pour un groupe adoptant LeSS ? S’il y a un département de gestion produits alors un responsable produit peut être un bon choix. Sinon, il faut chercher une personne du côté d’une unité métier qui puisse piloter l’initiative. La chose importante à garder à l’esprit est que le Product Owner pour le développement d’un produit devrait venir du côté métier.

Développement (de produits) à usage interne - un bon Product Owner pour le développement de produits à usage interne dans LeSS est (1) quelqu’un provenant d’un groupe qui utilisera le système, et (2) qui est étroitement impliqué et a une grande expérience sur le boulot réel que le système prendra en charge. Une telle personne est très proche des véritables utilisateurs.

Développement d’un projet - Ici le point-clé est que le Product Owner vient de l’entreprise qui bénéficiera du système et, comme pour le développement interne, qui est impliqué et dispose d’une grande expérience sur le travail opérationnel, et proche des utilisateurs.

Une variante habituelle à la fois dans le développement à usage interne et dans le développement d’un projet est lorsque le système sera amené à être utilisé par plusieurs départements. Un bon choix est alors de trouver une personne expérimentée au niveau opérationnel provenant de l’un des départements où se trouve les utilisateurs les plus importants et qui est intéressé par prendre le rôle et qui sait naviguer au niveau politique au sein de l’organisation.

L’illustration suivante montre le Product Owner dans différentes organisations :

Qui est le Product Owner selon les différents types de développement

Dans tous les cas, un super Product Owner est une personne passionnée par le produit.

Lorsqu’il est impossible de trouver le bon Product Owner immédiatement, vous pouvez tout de même rapidement démarrer une adoption de LeSS avec un Product Owner temporaire qui soit en mesure de comprendre ce qu’il se passe et prendre en charge les mécanismes du rôle mais qui n’est pas du côté métier. Laissons ensuite les équipes dérouler plusieurs Sprints avec le Product Owner temporaire jusqu’à ce que les problèmes majeurs soient résolus et - c’est important - jusqu’à ce que les équipes de développement puissent livrer un incrément vraiment ‘terminé’, déployable (ou quelque chose d’approchant) à chaque Sprint. Pourquoi ? Les équipes produits trouveront plus probablement et inspireront le bon Product Owner à plus long terme si elles peuvent montrer une nouvelle capacité qui soit attrayante et qui offre un bénéfice métier très tangible. Il est extrêmement important que tout le monde comprenne que le Product Owner temporaire est un bouche-trou. Nous utilisons régulièrement le terme “faux Product Owner” pour indiquer à quel point il peut être dommageable que ce poste de Product Owner temporaire se pérennise. Non seulement parce qu’un faux PO n’est pas le meilleur Product Owner mais également parce qu’il peut provoquer des dégâts en essayant de remplir un rôle pour lequel il n’est pas qualifié. Il doit être remplacé dès que possible pour éviter le risque d’aboutir à la création d’un produit de seconde classe.

Étape 3 : donner l’autorité et la responsabilité au vrai Product Owner

Le terme Product Owner n’est pas un nouveau nom donné à un responsable de projet traditionnel qui livre le résultat d’un travail basé sur un périmètre et une date contractualisés. Au lieu de cela, un Product Owner est une personne qui doit avoir l’autorité pour choisir et changer le contenu, les dates de livraison, les priorités, la vision, etc. Bien sûr, il collabore avec les parties prenantes, mais un vrai Product Owner est la personne qui détient l’autorité pour la prise de décision finale.

Cinq types de relations

Le Product Owner doit être en mesure de comprendre et travailler pour améliorer les cinq types de relations clés impactées par l’adoption de LeSS :

Les différents types de relation du Product Owner

  • Product Owner <-> Équipes

    Les équipes sont là pour aider le Product Owner à créer le meilleur produit possible pour le client. Elles doivent savoir quoi construire par la suite et si oui ou non ce qu’elles ont déjà réalisé a déjà atteint l’objectif. Le Product Owner doit savoir ce dont les équipes ont besoin et comment il peut être en mesure de les aider.

  • Product Owner <-> Clients

    Le Product Owner et les équipes essayent de créer le meilleur produit possible pour le client. Le client a besoin de savoir quand il aura les fonctionnalités qu’il souhaite, et peut être aussi le raisonnement sous-jacent aux priorités. Impliquez-les le plus possible en étant transparent. Le Product Owner doit apprendre leurs véritables objectifs ou problèmes en étant avec eux (ou entrevoir quelque chose au-delà même de leur vision) et collecter l’information qui l’aidera à bien prioriser.

  • Équipes <-> Clients

    Les équipes essayent de créer le meilleur produit pour le client. Elles doivent connaître le contexte des fonctionnalités et avoir une connaissance détaillée du domaine. Idéalement, les équipes co-créent les solutions directement avec les clients en capturant l’essence même (plutôt que la surface) des objectifs et des problèmes des clients. Les équipes doivent confirmer avec les clients qu’elles ont bien compris les exigences clarifiées ensemble.

  • Product Owner <-> Hiérarchie

    La hiérarchie au-dessus du groupe produit (responsables portefeuilles, cadres dirigeants, etc.) devraient considérer le Product Owner comme étant la personne qui a la responsabilité finale quant à la réussite du produit et qui doit en rendre compte. Il est responsable pour donner de la visibilité sur l’état d’avancement du développement et concrétiser le mandat (peut-être implicite) de la hiérarchie pour optimiser les impacts souhaités (par exemple, le ROI et les parts de marché). Le Product Owner, avec le soutien des Scrum Masters implique la hiérarchie pour aider à améliorer la structure de l’organisation.

  • Product Owner <-> Scrum Masters

    Les relations décrites ci-dessus font partie intégrante de l’art d’être Product Owner (ou “product ownership”), mais celle-ci est différente. Elle concerne les connaissances et le comportement du Product Owner. Les Scrum Masters doivent connaître les préoccupations, les questions et les obstacles du Product Owner afin d’être en mesure de l’aider. Un bon Scrum Master doit être une oreille bienveillante ou une épaule amicale sur laquelle pleurer. Les Scrum Masters éduquent et donnent du feedback au Product Owner afin qu’il puisse s’adapter en conséquence.

Les Réunions LeSS

Lorsque nous présentons LeSS, une question qui revient souvent est : “Comment un seul Product Owner peut-il gérer toutes ces réunions avec toutes ces équipes ?”. Fort heureusement, l’inquiétude qui se cache derrière cette question est qu’elle est basée en fait sur un malentendu. Le seul et unique Product Owner en LeSS assiste uniquement à des réunions individuelles même si c’est avec plusieurs équipes. Et le nombre d’équipiers dans ces réunions est gérable. S’il y a seulement deux équipes, tout le monde peut effectivement être présent et participer. S’il y a plusieurs équipes, deux représentants seulement de chaque équipe peuvent être présents.

Quelles sont les réunions LeSS auxquelles un Product Owner assiste et quelles sont les durées moyennes dans un Sprint type de deux semaines ?

Donc le temps total passé dans les évènements LeSS est, en moyenne, d’environ huit heures dans un Sprint de deux semaines.

Le Product Owner ne participe pas aux réunions spécifiques d’équipe que sont : La Planification du Sprint (2ème partie) (fr), La Mêlée Quotidienne (fr), les affinages de backlog faits par l’équipe (fr), les rétrospectives des équipes (fr).

Auteur : The LeSS Company B.V.
Source : Product Owner

Traducteur : Nicolas Mereaux
Relecteur : Fabrice Aimetti
Date de traduction : 23/06/2019

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.