LeSS - Le Product Owner

De Wiki Agile du @GroupeCESI
Révision datée du 23 juin 2019 à 15:53 par Nicolas Mereaux (discussion | contributions) (Page créée avec « Auteur : The LeSS Company B.V.<br /> Source : [https://less.works/less/framework/product-owner.html Product Owner (LeSS)]<br /> <hr /> Traducteur : [http://www.les-traduct... »)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à : navigation, rechercher

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


Traducteur : Nicolas Mereaux
Date de traduction : 23/06/2019



The Product Owner role in LeSS is conceptually the same as in one-team Scrum. However, at scale the focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.

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

Scaled Product Owner

Le Product Owner à grande échelle

It’s common in large-scale product development for different people to pull in different directions and for subgroups to focus on local sub-optimizations. Maintaining one Product Owner with one Product Backlog supports whole-product focus.

S’il est une chose assez répandu 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.

In traditional large-scale product groups, there’s a group (often product managers) that focuses outward and a group (usually developers) that focuses inward — and never the twain shall meet. In LeSS, the one Product Owner has lots of free time to focus outward on customers and their priorities while also being able to spend some time looking inwards to the teams. She acts as a connector, bringing teams and customers/users together so the teams become more customer focused.

Dans les groupes produit à grande échelle rencontrés traditionnellement, 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]https://less.works/less/principles/customer-centric.html).

In contrast with other scaled Scrum approaches, it’s possible in LeSS to effectively scale the Product Owner role with just one person because there are fewer roles and positions, and less complexity.

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é.

Prioritization over Clarification

Priorisation plus que clarification

There are two key information flows in Scrum related to the Product Owner: (1) prioritizing (ordering) items in the Product Backlog and (2) clarifying items in the Product Backlog. In the first flow (prioritization), information related to profit drivers, strategic customers, business risks, and other business concerns is sought and analyzed. In the second flow (clarification), information is sought to detail the behavior and qualities of items, the user experience, and other feature design concerns.

Il y a deux flux d’informations-clés dans Scrum liés au Product Owner : (1) la priorisation (ordonnancement) des éléments dans le Backlog de Produit et (2) la clarification des items 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 business sont recherchées et analysées. Dans le second flux (clarification), l’information est recherchée pou détailler le comportement et les qualités intrinsèques des items, l’expérience utilisateur, et à d’autres préoccupations sur la conception des fonctionnalités.

A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, she encourages and helps the teams enter into a direct conversation with true users and customers for clarification. She acts as a connector, not an intermediary.

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 vrais utilisateurs et les vrais clients pour plus de clarification. Il agit en tant que connecteur, pas en tant qu’intermédiaire.

Why emphasize direct interaction between teams and customers/users? Reasons include: (1) avoiding information loss from handoffs, (2) fostering co-creation of solutions to real customer problems, and (3) improving motivation and empathy for customers by having developers collaborate with them directly.

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

It’s worth noting that when the teams do most of the clarification work the Product Owner has more time and energy to focus on the big picture, continuously prioritizing and exploring new and strategic opportunities.

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 ou stratégiques.

Find a Product Owner Given Your Type of Development

Trouver un Product Owner selon votre type de développement

Step 1: Know Your Development Type

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

Finding the right Product Owner depends on knowing the type of development you are doing:

Trouver le bon type de Product Owner dépend de la connaissance du type de développement que vous faîtes :

  • Product development—For external customers or a market.
  • Internal (product) development—For one or more users within the company. The development group is usually called IT or Systems Development.
  • Project development—Usually for one external customer. The work is organized and contracted as a project of some kind although that does not necessarily mean a fixed scope/date/cost project contract. The development company is usually an outsourcer or systems-integrator. The customer, or client company, includes both the purchasing entity and the users, who are not always in the same department.
  • 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’elle soit bien que cela ne signifie pas pour autant un contrat pour le projet avec un(e) périmètre/date/coût fixe. L’entreprise 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 clients, qui ne sont pas nécessairement dans le même département.

Step 2: Finding the right Product Owner

Étape 2 : trouver le bon Product Owner

Product development—The company will have either (1) a business unit driving the product initiative (e.g., Retail Banking), or (2) a Product Management department driving the initiative. Traditional Product Management is responsible for customer and competitor analysis, product vision, coarse-grained feature selection and prioritization, product roadmap, and other non-technical activities. They don’t manage the work of a traditional development group.

Développement de produits - l’entreprise aura soit (1) une unité opérationnelle 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. Il ne gère pas non plus le travail d’un groupe de développement traditionel.

Where to find a Product Owner for a group adopting LeSS? If there’s a Product Management department, then a Product Manager can be a good choice. Otherwise, look for a person from the business unit that’s driving the initiative. The important thing to keep in mind is that the Product Owner for product development should come from the business side.

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é opérationnelle 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.

Internal (product) development—A good Product Owner for internal product development in LeSS is (1) from within the group that will use the system, and (2) is closely involved in and deeply experienced in doing the real work that the system will support. They are very close to the real users.

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) 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 vrais utilisateurs.

Project development—The key point is that a Product Owner is from the company receiving the system and, as with internal development, is involved in and deeply experienced in the hands-on work, close to users.

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.

A common variant for both internal and project development is when the system will be used by many departments. Then, a good choice is an experienced, hands-on individual from one of the major user departments who is interested in taking on the role and has political savvy.

Une variante que l’on rencontre habituellement à 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 un individu expérimenté 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.

The following figure shows the Product Owner in different organizations:

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

<figure class> Who is the Product Owner in Different Types of Development <figcaption> [Download PNG]

Qui est le PO

In all cases, a great Product Owner has a passion for the product.

Dans tous les cas, un grand Product Owner est une personne ayant une passion pour le produit.

When it is impossible to find the right Product Owner immediately, you can quickly start a LeSS adoption with a temporary Product Owner who understands what’s going on and can perform the mechanics of the role but is not from the business side. Let the teams complete several Sprints under the temporary Product Owner until the major kinks are worked out and — this is important — the development teams can deliver a truly ‘done’, shippable increment (or something close) every Sprint. Why? The product teams will be more likely to find and inspire the right longterm Product Owner if they can show a compelling new capability that offers very tangible business benefit. It’s terribly important that everyone understand that the temporary Product Owner is a placeholder. We often use the term “fake Product Owner” to indicate just how damaging this temporary Product Owner can be. Because the fake PO is not only not the best Product Owner but also she can cause damage trying to fill a role for which she is not qualified. She must be replaced as soon as possible to avoid the risk of creating a second-class product.

Lorsqu’il est impossible de trouver le bon Product Owner immédiatement, vous pouvez tout de même 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é’, livrable (ou quelque chose d’approchant) à chaque Sprint. Pourquoi ? Les équpes 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 - terriblement - 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érénise. 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 de voir aboutir à la création d’un produit de seconde classe.

Step 3: Give Authority and Responsibility to a Real Product Owner

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

Product Owner is not a new name for a traditional project manager who delivers a scope and date contract of work. Rather, a Product Owner must have the independent authority to choose and change content, release dates, priorities, vision, etc. Of course she collaborates with stakeholders, but a real Product Owner has final decision-making authority.

Le terme Product Owner n’est pas un nouveau nom donné à un responsable de projet traditionnel dont le travail est de livrer le résultat d’un travail basé sur un périmètre et une date donnée 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 livraisosn, 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.

Five Relationships

Cinq types de relations

The Product Owner needs to understand and work to improve five key relationships that are affected by LeSS adoption:

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 :

<figure class> Product Owner Relationships <figcaption> [Download PDF]

Les différents types de relation du Product Owner

  • Product Owner<–>Teams

  • Product Owner <-> équipes

    The teams are there to help the Product Owner create the best possible product for the customer. They need to know what to build next and whether or not what they have already built has hit the mark. The Product Owner needs to know what the teams need and how she can help them.

    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à fait mouche. Le Product Owner doit savoir ce dont les équipes ont besoin et comment il peut être en mesure de les aider.

  • Product Owner<–>Customers

  • Product Owner <-> Clients

    The Product Owner and teams are trying to create the best possible product for the customer. The customer needs to know when they will have features they care about, and perhaps the reasoning behind the priorities. Involve them as much as possible by being transparent. The Product Owner needs to learn their real goals or problems with them (or envision something beyond their vision) and collect the information that will help him prioritize well.

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

  • Teams<–>Customers

  • équipes <-> clients

    The teams are trying to create the best possible product for the customer. They need to know the context for features and have detailed domain knowledge. Ideally, teams co-create solutions directly with customers by grasping the customers’ essential (rather than superficial) goals and problems. Teams need to confirm with customers that they fully understand the requirements they are clarifying together.

    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 le seul côté superficiel) 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<–>Higher Management

  • Product Owner <-> encadrement plus haut dans la hiérarchie

    Higher management beyond the product group (portfolio managers, C-level executives, etc.) should view the Product Owner as having the final accountability and responsibility for product success. She is responsible for making the development status visible and realizing higher management’s (perhaps implicit) mandate to optimize desired impacts (e.g., ROI and market share). The Product Owner, with support from Scrum Masters, engages higher management’s help to improve the organizational design.

    Les supérieurs hiérarchiques 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 rendre le statut du développement visible et concrétiser le mandat des supérieurs hiérarchiques (qui est peut être implicite) pour optimiser les impacts souhaités (par exemple, le ROI et la part de marché). Le Product Owner, avec le support des Scrum Masters implique ces supérieurs hiérarchiques dans l’aide qu’ils peuvent apporter pour améliorer la structure de l’organisation.

  • Product Owner<->Scrum Masters

  • Product Owner <-> Scrum Masters

    The relationships above are directly related to “product ownership,” but this one is different. It relates to Product Owner knowledge and behavior. The Scrum Masters need to know the Product Owner’s concerns, questions, and obstacles so they can help. A good Scrum Master can be a friendly ear or a shoulder to cry on. Scrum Masters educate and feed back so Product Owners can adapt.

    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 des retours d’informations au Product Owner afin qu’il puisse s’adapter en conséquence.

LeSS Meetings

Les réunions LeSS

When we introduce LeSS, a frequent question is, “How is one Product Owner going to manage all of those meetings with all of those teams?” Fortunately, the concern behind that question is based on a misunderstanding. The one Product Owner in LeSS only attends single meetings even though there are multiple teams. And the number of team members at those single meetings is manageable. If there are just two teams, everyone can effectively attend and participate. If there are many teams, only two representatives from each team may attend.

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 peut être présent.

What LeSS meetings does the Product Owner attend and what is their average duration in a typical two-week Sprint?

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 ?

---

So the total time spent in LeSS events is, on average, about eight hours in a two-week Sprint.

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

The Product Owner does not attend the team-specific meetings: Sprint Planning Two, Daily Scrums, team PBRs, team Retrospectives.

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