LeSS - Product Owner de Domaine

« Portail LeSS < Portail LeSS Huge

Un Product Owner de Domaine (NdT : APO - Area Product Owner) est spécialisé dans un domaine centré sur le client, il agit comme un Product Owner en relation avec les équipes du domaine (cf. schéma ci-après). Un Product Owner de Domaine fait le même travail qu’un Product Owner mais avec une perspective plus limitée même si elle reste centrée sur le client.

Équipe Product Owner

Les Product Owners de Domaines et le Product Owner forment ensemble une équipe, l’équipe Product Owner. Cette équipe prend des décisions pour prioriser à l’échelle du produit, mais le Product Owner prend toujours la décision finale. Les décisions sur le périmètre et le délai restent également du ressort du Product Owner, il décide quand livrer quoi.

Les équipes sont réparties sur les différents domaines d’exigence en se basant sur les priorités du Backlog Produit. Les domaines sont de différentes tailles en termes d’effort et contiennent donc un nombre différent d’équipes. Ce n’est pas une bonne idée d’avoir des domaines trop petits parce que cela génère beaucoup de backlogs et beaucoup de Product Owners de Domaine. On perd la vue globale et les équipes développent des features de valeur faible. Préférez plutôt quelques petits domaines associés à un seul domaine plus large, ceci afin d’augmenter la flexibilité au sein de ce domaine. D’un autre côté, des domaines trop grands sont difficiles à gérer par un seul Product Owner de Domaine. Pour trouver un bon équilibre, envisagez un minimum de quatre et un maximum de dix équipes par domaine.

Pourquoi des Product Owners de Domaine

La raison principale pour avoir des Product Owners de Domaine, c’est d’éviter que le Product Owner soit complètement surchargé. Sans Product Owner de Domaine, le Product Owner est surchargé car :

• le Product Owner a trop d’équipes en face de lui
  Avec toutes les activités que doit réaliser un Product Owner, il semble impossible qu’il puisse travailler avec plus de quelques équipes. Comment résoudre cette situation ? Une manière de le faire est de déléguer le travail de clarification des éléments du Backlog Produit aux équipes en intégrant des experts sur le sujet dans l’équipe. Une autre solution est d’avoir une personne qui assiste le Product Owner dans ce travail de clarification. Elle rejoint l’Équipe Product Owner mais ne prend pas de décision quand à la priorisation. En utilisant ce dispositif, un Product Owner peut travailler avec un nombre d’équipes compris entre cinq et dix. Prenez soin de ne pas dépasser cet intervalle, vous risqueriez de générer un trop-plein d’informations pour le Product Owner et de compliquer la planification de l’itération.
• le Backlog Produit devient trop grand
  La [Pensée Lean (en)]http://less.works/less/principles/lean-thinking.html favorise le recours à des lots de petites tailles et à des cycles courts. Nous proposons que chaque équipe ait au minimum quatre Éléments de Backlog Produit par itération et qu’elle puisse les terminer au sein de cette itération en toute indépendance. Avec 50 équipes, cela mène à un Backlog Produit de 200 éléments, juste en une seule itération. Prioriser 200 Éléments de Backlog Produit par itération représente trop de travail pour un seul Product Owner.
• les Équipes travaillent sur le système global
  C’est une bonne idée d’avoir des Équipes Feature, et qu’elles en apprennent plus sur les nouvelles parties du système. Mais attention, trop d’apprentissage sans livrer de valeur n’est pas intéressant. C’est ce qui peut arriver lorsque des équipes travaillent sur des features qui leur sont complètement inconnues. Elles n’ont pas l’opportunité de se spécialiser et cela affecte la vélocité de l’équipe. Comment trouver un bon équilibre ?

Auteur : The LeSS Company B.V.
Source : Area Product Owner - Large Scale Scrum (LeSS)

Traducteur : Fabrice Aimetti
Date de traduction : 31/12/2016

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.