PO — Product Owner

Le métier de Product Owner est un métier difficile. C'est un métier pour mouton à cinq pattes qui sera aussi … caméleon !

Cette femme, cet homme doit être le trait d'union entre toutes les parties prenantes et l'équipe qui va construire la solution demandée (ou même, les équipes). Il/Elle doit être capable de parler plusieurs langues (jargons), prendre des postures différentes, examiner le ou les produits dont il a la charge selon tous les angles possibles. Il doit être capable de comprendre la technique, de comprendre les enjeux de la vente, de l'après-vente, du marketing, des utilisateurs finaux, de ceux en charge des opérations, etc. Il doit être capable d'établir une feuille de route pour le produit à construire, une feuille de route qui fait sens pour tous les intervenants. Ce n'est donc pas un métier facile, loin s'en faut.

Scrum, XP, at scale, Kanban, Lean, etc. et Waterfall

Dépendant de l'organisation dans laquelle le métier de Product Owner se pratique, ses responsabilités évoluent. Ce sera une question de gouvernance, de définitions, de descriptions de fonctions, etc.

Cela sera aussi une question de maturité de l'entreprise sur la voie de l'Agilité.

Au fil du temps et des expériences, l'entreprise s'engagera sur différentes voies. Le cheminement le plus classique est de partir vers Scrum, puis de bifurquer vers XP pour en intégrer les pratiques techniques, avant de s'apercevoir que l'équipe, d'isolée au départ, est maintenant en contact avec de multiples autres équipes et qu'il est nécessaire de coordonner leur travail pour aboutir à la valeur globale du produit à concevoir, auquel cas on se tournera naturellement vers des modèles d'Agilité à l'échelle (at scale) comme SAFe, puis on réalise qu'il fauit éviter les pièges des dépendances d'entrée et/ou de sortie et on se tournera assez naturellement vers des flux continus de releases comme c'est souvent le cas avec Kanban et enfin, on s'aperçoit également que Lean apporte ses réponses à de multiples soucis auxquels on fait face. Enfin, cela c'est sans compter sur des couches encore Waterfall dont l'entreprise pourrait ne pas s'être débarrassée.

Le/la Product Owner, lui/elle, n'a pas à se soucier de tout cela : son métier c'est de livrer le produit attendu le plus rapidement possible.

Le/la Product Owner, lui/elle, n'a pas à se soucier de tout cela : son métier c'est de livrer le produit attendu le plus rapidement possible, produit qui sera un concentré de valeur(s)^[1] , et chacun a sa petite idée de ce qu'il entend par valeur : pour le responsable des ventes ce sera d'avoir un produit avec lequel il atteindra ses objectifs de vente, le marketing manager,lui, est intéressé par le meilleur product-mix, le responsable des opérations ce sera un produit qui tourne sans qu'il en entende parler, le client ce sera le produit qui l'aide à résoudre son problème (Job To Be Done), etc. etc.

Le premier métier du Product Owner

Le premier métier du Product Owner c'est de définir son ou ses produits en accordance avec sa place de marché. On pense souvent là aux caractéristiques/propriétés du produit (les fameux requirements) mais cela n'est qu'une vue étriquée. Son boulot, de ce point de vue, doit être celui d'un visionnaire du marketing. Il ne pourra pas être Marketing Manager, certes, mais s'il en avait la sensibilité, ce ne serait pas plus mal !

Le premier métier du Product Owner c'est de définir son ou ses produits en accordance avec sa place de marché, et sa place de marché c'est tant une localisation, des concurrents que des clients et utilisateurs.

Cette vision doit s'articuler dans le temps ! C'est au Product Owner qu'il revient d'établir une feuille de route, une roadmap, et cette roadmap ce n'est pas une roadmap du style…

Ça, c'est une ligne de temps technique qui va parfaitement convenir à un Chef de Projet, à un Tribe Lead, à un Tribe Scrum Master, à un Programme Manager, à un auditeur de gouvernance mais PAS DU TOUT à un responsable Marketing, à un Responsable des ventes, à un client ! Il faut que les phases qui sont renseignées produisent du sens, aient une signification, incitent au voyage.

Pour faire sens, la livraison finale devrait générer une image positive en couleurs dans l'esprit de ceux qui vont lire la feuille de route ! Toutes les phases d'ailleurs !

La valeur

Le Scrum Guide — mais vous avez bien compris que'il va falloir dépasser Scrum — dit le Product Owner est responsable de l'optimisation de la valeur du produit résultant du travail de l'équipe Scrum. Certes. Le problème là-dedans c'est qu'à moins de parler d'un produit comme Spotify (entreprise monoproduit avec de petites équipes de développement peu liées, du moins au départ) le Product Owner va probablement devoir agir à l'intersection de plusieurs équipes^[2] . Cela veut dire quoi concrètement ?

Et bien cela veut dire qu'il faut intégrer cette vision multi-teams. Plutôt que d'avoir la vue suivante de l'équipe...

On devra plutôt avoir cette vue-ci…

Cette illustration ne signifie pas que le Product Owner supervise les équipes pas plus qu'elle signifierait le moindre lien hiérarchique. Elle exprime le besoin de cohérence et de coordination. C'est la vue que SAFe a apportée avec son Agile Release Train, une vue où un train (une équipe d'équipes établies dans une durée longue) construit, livre et souvent exploite (You Build It, You Run It) de manière incrémentale une ou plusieurs solutions dans un flux de valeur.

Le travail des équipes est alors parallèle et le grand défi est de pôuvoir synchroniser leur rythme. Ou alors … de s'empêcher de le synchroniser (jusqu'à un certain point) par l'instauration d'un principe supérieur comme Chaque équipe doit pouvoir développer, déployer et tester indépendemment de toutes les autres. C'est ce principe que je défends ardemment depuis des années car c'est aussi le plus prometteur pour qui ne souhaite pas entrer dans des "guerres" de dépendances. Ce n'est malheureusement pas toujours possible, je dois bien l'admettre. Cependant, l'application de ce principe supérieur peut nous exonérer d'entrer dans des schémas de dépendances classiques, trop nombreuses et rédhibitoires. Voci une autre vue de ce travail en parallèle où chaque équipe contribue à générer une valeur globale :

Vision et objectifs

Le Product Owner doit apporter vision et objectif. Pllus que cela même ! La vision et les objectifs doivent être partagés : chacun doit les comprendre et y adhérer.

Je ne connais pas de meilleure méthode que celle du Toyota Kata !

1. On expose clairement l'objectif de (très) long terme
2. On prend conscience de sa position du moment
3. On établit un objectif (quoi, quand)
4. On effectue des pas dans la direction de l'objectif (3)
5. On boucle sur l'étape 2

Retour sur roadmap — feuille de route

Travailler en sprints ou itérations c'est bien mais ce n'est pas nécessairement un objectif premier. L'objectif premier reste de livrer quelque chose d'utilise à la satisfaction de toutes les parties prenantes.

La vision de long terme et les objectifs ne peuvent pas s'exprimer dans l'horizon d'une itération. Par ailleurs, si vous travaillez plutôt en mode Kanban, vous allez livrer aussi vite que vous pouvez (SAFe parle de Release on Demand), pas nécessairement au bout d'une itération (il se pourrait même qu'il n'y en ait tout simplement pas).

L'objectif premier reste de livrer quelque chose d'utilise à la satisfaction de toutes les parties prenantes.

Alors, vous avez cette notion de cycle (un Product Increment, dans le temps, en SAFe). Une forme d'itération trimestrielle.

J'ai l'habitude de conseiller aux Product Owners de travailler en cycles de 13 semaines (1 année = 52 semaines = 4 cycles de 13 semaines). Voici comment s'articule la préparation des cycles (je reprends un schéma que j'avais réalisé pour une préparation de ce style pour 2022-2023:

Dans le cas d'équipes qui préfèrent le mode Kanban avec livraison/déploiement à la volée, ignorez les itérations : vous avez autant de déploiements que les équipes le jugent utile.

Ce qui m'apparait déterminant ici, c'est que le Product Owner met à jour la vision et les objectifs à la bordure des cycles, toutes les 13 semaines. C'est la raison pour laquelle je souhaitais introduire cette notion de cycle ici.

Par ailleurs, ce que nous montre aussi cette illustration, c'est que le travail du Product Owner ne s'arrête pas à définir un backlog d'équipe (ou product backlog, une appelation que j'aime moins). Pendant que l'équipe (ou les équipes) travaillent à construire les solutions, le Product Owner est en permanente définition et préparation du prochain cycle. C'est ce que montrent les 4 flèches du dessus : Preparation Cycle2 2022, Preparation Cycle3 2022, etc.

Ordonnancer, prioriser le backlog

Je préfère le terme Team Backlog à Product Backlog. En effet, dans le cas d'équipes assemblées sur le long terme (rappelez-vous la définition du Agile Release Train chez SAFe: The Agile Release Train (ART) is a long-lived team of Agile teams that incrementally develops, delivers, and often operates one or more solutions in a value stream.) et étant donné la nature du cycle de vie d'un produit, il y a fort à parier que vos équipes auront moins de choses à faire lorsque le produit dont elles s'occupent atteint sa phase de maturité. Dès lors, pour garder des équipes minimales assemblées sur du long terme, vous serez amené à ajouter à leur backlog … d'autres produits ou projets. C'est la raison pour laquelle je parle plutôt de Team Backlog.

Bref, lorsqu'on en vient à prioriser le travail à a faire Scrum nous dit d'effectuer cette priorisation sur base de la valeur attribuée aux items dans le backlog.

Je suis d'accord avec cette approche mais je lui adjoins la notion de ratio, un ratio que j'appelle LEAF: le least effort at feature. Il s'agit de programmer d'abord les choses dont le ratio "Valeur / Coût" est le plus élevé. Voici ce que cela donne:

Il est évident qu'on ne parle pas ici de tâches techniques ! On parle de fonctionnalités Business.

Le Product Owner est le trait d'union entre les parties prenantes

Si on se rappelle de ce que l'objectif est de livrer quelque chose d'utilise à la satisfaction de toutes les parties prenantes il semble évident que le Product Owner doit être ce trait d'union entre toutes les parties.

Ce n'est pas sans conséquence car, en effet, il sera plus difficile à une personne externe de jouer ce rôle de trait d'union si on compare cela à une personne issue du "terroir" qui est immergée dans l'organisation depuis plusieurs années.

Cependant, une autre réalité frappe à la porte : le bon Product Owner est un mouton à cinq pattes qui ne se trouve pas facilement dans l'organisation car ce n'est pas comme si l'organisation avait, toute prête à assigner, de multiples personnes en attente d'un rôle de Product Owner. C'est donc très normal de trouver des Product Owner externes ! Qu'il me soit pourtant permis de dire qu'on sera bien inspiré à demander à ces Product Owners externes de former des Product Owners internes ou de leur permettre de rejoindre l'organisation, plus tard, comme internes.

Une démo, c'est pour le Business, par le Business

La démo (partie du Sprint Review) c'est le Product Owner qui s'y colle, et le Product Owner est une forme de représentant du Business. Ainsi, le PO ne découvre pas le résultat de l'itération lors de la démo, non pas, il l'explique et ce qui lui est demandé c'est de pouvoir expliquer aux parties prenantes d'où il est parti (point 2 du kata), où il souhaitait en arriver (le point 3 du kata), de montrer les pas qui ont été entrepris (points 4 du kata) et de boucler sur le nouveau point 2 (où en est-on?). Á cette condition, il est capable d'expliquer l'incrément visé par le Review.