Vos Product Owners ne sont pas suffisamment proches de leurs Clients. Vous n’êtes pas vraiment agile et vous devez y remédier !

No country for old PO

1986.

Gauthier se sert une tasse de café en baillant et ouvre la page emploi du journal qu’il parcourt distraitement tout en rembobinant une cassette d’Iron Maiden avec un crayon. Les annonces de recrutement pour le poste de Product Owner fleurissent en ce moment, publiées par des entreprises en quête de vitesse et de flexibilité dans ce monde compétitif et en constante évolution.

Stop ! Pause.

Iron Maiden OK. Mais mettre à la même époque les mots « Product Owner » et « Est-Berlinois » c’est un poil abusé, pensera le lecteur qui a passé l’âge.

Allez. Partons du principe que… Lecture.

En 1986 donc, Hirotaka Takeuchi et Ikujiro Nonaka, respectivement professeurs à Harvard et à l’Université Hitotsubashi de Tokyo, publient dans la Harvard Business Review un papier intitulé « The New New Product Development Game ». Celui-ci commence par une phrase qui paraîtra étrangement actuelle au lecteur habitué des articles sur l’agilité, et joue d’une certaine méthaphore sportive que les pratiquants de Scrum reconnaîtront aisément :

"Dans le monde d’aujourd’hui, compétitif et changeant, la vitesse et la flexibilité sont des atouts importants. Les entreprises réalisent que la veille méthode séquentielle de développement de nouveaux produits ne convient plus. Au lieu de ça, des entreprises au Japon et aux USA utilisent une méthode holistique – Comme au rugby, la balle passe de mains en mains entre les membres de l’équipe pendant que celle-ci parcourt le terrain de façon soudée."

Les auteurs expliquent que pour pouvoir sortir du produit compétitif dans un contexte de marché en perpétuel mouvement, les organisations doivent intégrer et mettre en œuvre les principes suivants :

• Donner à l’équipe en charge du produit des objectifs extrêmement ambitieux (tiens, bonjour les OKR !) et une grande latitude pour les atteindre. Les auteurs poussent les équipes à se montrer audacieuses et créatives face à ce versant nord de l’Everest que personne ne sait gravir.
• Des équipes autoorganisées et dotées d’une liberté d’approche dans le développement du produit, pluridisciplinaires, dont les membres aux personnalités variées sont prêts à se dépasser pour affronter les objectifs ambitieux qui leur sont confiés. Il est très clairement indiqué que l’équipe doit être seule responsable des orientations du produit et des choix stratégiques qui y sont associés, ce qui implique bien entendu une capacité à entendre la voix du client et à en tirer des enseignements. Le management étant cantonné à un simple rôle de financeur. J’aime tout particulièrement cette phrase prononcée par un exécutif : « Nous ouvrons notre portefeuille et fermons notre bouche. ». Voilà. Ça, c’est fait.
• Une parallélisation des différentes phases de développement du produit (bench, étude, fabrication…), avec des allers-retours. Aujourd’hui massivement véhiculé par le terme « itération», anglicisme de « iterate », ce principe constitue la base de nos sprints qui poussent à faire « un peu de tout » dans une courte période pour apprendre, progresser, et avancer d’une case dans le développement du produit. Vous y aurez évidemment reconnu l’antithèse du cycle en V, et les grands principes des méthodes agiles qui visent à mettre le client au centre de la boucle « Test&Learn ».
• L’apprentissage continu, présenté par le terme « multilearning » comme un aspect indispensable du développement produit, puisque l’équipe s’engage sur sa démarche avec beaucoup d’incertitude, et beaucoup de liberté pour pouvoir la lever. L’importance de l’essai-échec avec toute la bienveillance managériale que cela implique y est abondamment défendue car permettant aux membres de l’équipe d’évoluer, d’acquérir de nouvelles compétences… Bref, de se transformer en machine à résoudre des problèmes. D’ailleurs, le multilearning ne s’arrête pas à l’apprentissage autour du produit, il englobe un état d’esprit plus large qui pousse les membres de l’équipe à « hybrider » leurs compétences en faisant de la veille et du développement personnel.
• Le transfert de connaissance qui prône l’export des pratiques, techniques, connaissances, méthodes et autres briques techniques développées par l’équipe dans sa course effrénée vers le sommet pour qu’elles puissent servir à d’autres. Voire à être industrialisées au sein de l’entreprise. Transformer une pratique avant-gardiste en quelque chose de normal implique un devoir de mémoire et de pédagogie qui entre dans la lettre de mission de l’équipe produit. Le consultant de 2022 en quête d’un bon mot écrira dans sa slide : « L’équipe produit comme catalyseur de changement dans l’organisation ».
• Et enfin mon préféré : ce que les auteurs nomment le « Contrôle Subtil ». On trouve dans ce paragraphe un condensé du manuel du parfait petit Manager 2.0 qui veille à ce qu’autonomie et auto-organisation ne deviennent pas le carburant d’un joyeux chaos. Le Contrôle Subtil n’est autre qu’un mélange d’holacratie et de responsabilisation par les pairs. Sans surprise, on y découvre que l’équipe doit être constituée de personnes qui ont oublié d’être bêtes si on veut que ça fonctionne, ainsi que d’autres portes fort pertinentes mais que nous ne décrirons pas ici tant elles ont été ouvertes depuis.

Sur ce dernier point, il est intéressant de souligner que le contrôle des équipes défendu dans l’article ne doit pas être fait directement par un management envahissant et intrusif, mais par la mise en place de principes d’organisation et de rituels qui poussent les membres de l’équipe à s’auto évaluer dans une perpétuelle quête du droit chemin. L’un de ces principes d’organisation est de pousser les ingénieurs (sic) à sortir du bureau pour aller sur le terrain et rencontrer les clients afin de challenger leurs propres certitudes. Les lecteurs qui me connaissent me voient venir gros comme le Brésil. Mais nous y reviendrons plus tard !

Ellpse.

Reservoir PO

L’eau a coulé sous les ponts depuis 1986.

Le Manifeste Agile est passé par là, la pratique de l’agilité s’est démocratisée dans le monde du développement logiciel, dépassant ses frontières pour toucher l’organisation tout entière.

Tout le monde veut itérer, tout le monde veut être agile !

L’essor de Scrum a popularisé un certain nombre de rituels d’auto-organisation des équipes, en particulier les sacro saints Daily, Sprint Reviews et autres Planning Poker qui parlent bien aux diverses parties prenantes grâce à leur format court et actionnable, très en rupture par rapport aux vieilles pratiques, et dont la promotion est assurée par l’abondance de citations anglo-saxonnes à base de « pizza », de « stand-up » et de « fail fast ». D’ailleurs, il faut rendre à César ce qui appartient à César : la méthodologie Scrum est plutôt bien appliquée dans les organisations 1^ères de cordée. Ça « Backlog », ça « Kanban », et ça « Rétro » plutôt pas mal.

Pourtant, bien faire du Scrum n’est pas une garantie à l’agilité.

Un grand nombre d’organisations qui l’ont mis en place avec succès ne récoltent pas les fruits de ce qui est avant tout une capacité à s’adapter rapidement au changement.

Il y a un certain nombre de raisons à cela, et nous allons nous intéresser dans cet article à l’une d’entre elles tout particulièrement : le rôle de Product Owner n’est pas utilisé à bon escient, et les équipes ont par conséquent rarement l’occasion de parler aux clients finaux.

Reprenons les 6 piliers du « New New Product Development » de Takeushi et Nonaka :

1. Pose d’objectifs très ambitieux
2. Equipes autoorganisées et dotées d’une liberté d’approche dans le développement du Produit
3. Parallélisation des différentes phases de développement du produit
4. Apprentissage continu à tous les niveaux
5. Transfert de connaissance
6. Contrôle subtil, alignement et lien direct avec le client

Pris en dehors de leur contexte, ces 6 préceptes sont mot pour mot repris dans les schémas directeurs vendus par toute agence de conseil qui se respecte, et vantés par les directions en charge du chantier « d’agilisation  » en interne. Et pour cause : ils constituent depuis les années 80 la base d’une Organisation Produit efficace et VRAIMENT agile.

Hélas, peu sont tenus. Je veux dire VRAIMENT tenus.

1. La pose d’objectifs ambitieux, lorsqu’elle existe, et trop souvent considérée par les équipes comme une liste de KPI source de représailles en cas de non-atteinte. Que ce soit vrai ou pas ne change pas grand-chose étant donné que ce genre de mécanisme n’a que l’efficacité que les équipes veulent bien lui accorder. Ce qui était à l‘origine boussole, soleil et constellations, est devenu liste de coordonnées GPS à suivre. Et tant pis si la route passe par un pont qui n’existe pas.
2. Si dans les organisations les plus mûres, les équipes sont effectivement auto-organisées dans leurs rituels et façon de travailler, elles sont en revanche loin d’être aux commandes de leur backlog (un vœu pieux, déclarent souvent les « agilistes » en interne quand on leur pose la question). Auto-organisation oui, liberté de rencontrer son client et de choisir son approche dans le développement du produit beaucoup moins.
3. La parallélisation des phases de développement du produit est également un principe bien compris, et se traduit par le rythme en Sprints que nous connaissons bien. Mais étant donné que les équipes ne sont pas complètement aux commandes de leur Produit, et qu’elles n’intègrent pas toujours les compétences pour cocher toutes les cases, elles doivent s’entourer d’une myriade de parties prenantes secondaires plus ou moins sollicitées qui rend impossible toute velléité d’agilité dans la prise de décision. Sans compter l’impressionnante ingénierie de l’organisation nécessaire pour lancer les sujets et tenter d’anticiper tout ce qui pourrait venir sauter à la figure plus tard, alors que l’agilité a justement pour but d’intégrer à la stratégie Produit la gestion temps-réel des imprévus.
4. et 5. L’apprentissage continu et le transfert de connaissance sont plus ou moins bien faits selon le temps dont disposent les membres de l’équipe. C’est-à-dire pas beaucoup compte tenu des charges de travail et de la quantité de réunions qui peuplent les agendas.
5. Quant au contrôle subtil, il n’a malheureusement rien de subtil. La capacité de la hiérarchie à lâcher la bride et à laisser une véritable autonomie terrain dans la prise de décisions stratégiques étant souvent l’un des derniers bastions à tomber dans les grandes organisations.

Au lieu d’utiliser ces préceptes pour transformer les entreprises de l’intérieur, changer radicalement la manière dont les produits sont conçus, et affranchir les équipes des codes en place pour mettre le client au cœur de leur démarche, nous les avons tordus pour les faire rentrer dans les murs rigides du système existant au détriment de leur valeur profonde, et en donnant une importance démesurée au dogme de l’organisation.

Comme un vacancier soutenant mordicus que « tout rentrera à l’aise » quitte à conduire assis sur une glacière, la vitre arrière obstruée et un parasol pointé dangereusement sur la nuque du passager, plutôt que de réduire son volume de bagages ou de changer de voiture.

C’est fort dommage, car malgré tous les coachs, outils, rituels et méthodologies que l’on peut mettre en place, une chose est certaine : aucune organisation ne sera vraiment agile sans aller au bout de l’état d’esprit qu’impose une telle transformation.

PO Lost in Translation

Les principes, c’est bien beau.

Encore faut-il les mettre en œuvre au quotidien et veiller à ce qu’ils aident à délivrer du Produit de qualité. Pour cela il faut des têtes, des principes et de la méthode. Ainsi, au fil des années de nombreuses méthodes ont vu le jour, libérant sur ce marché très lucratif de « l’agilité à l’échelle » leurs lots de rôles, frameworks, matrices de responsabilités et autres rituels.

L’une d’entre elles, nommée Scrum en référence à la fameuse métaphore de Takeuchi et Nonaka (« Scrum » est un bien vilain mot en français, mais signifie « mêlée » en anglais), met en place un cadre pour créer des produits par l’apprentissage continu et la créativité, afin de maximiser leur valeur pour les clients. Elle est elle-même issue du Manifeste Agile, le fameux, lui-même tiré de… Bref, vous avez compris !

Outre les principes et rituels que nous ne détaillerons pas ici (le web n’est pas avare en contenu de qualité sur le sujet), Scrum a mis à disposition de ses utilisateurs un rôle faisant corps avec l’équipe produit : le Product Owner.

Le Product Owner tel que défini par les créateurs de Scrum, cristallise un certain nombre des principes originels de l’Organisation Produit, et a plusieurs responsabilités :

• Celle d’un pilote de produit, d’abord. Véritable vinaigrette sur la salade servie aux clients, le PO a cette responsabilité de maximiser la valeur délivrée aux utilisateurs par la définition des objectifs et des fonctionnalités offertes, mais également par la vérification que ce qui est délivré apporte bien la valeur attendue.
• Celle d’un communiquant, ensuite. Auprès de l’équipe à qui il faut transmettre et expliquer le backlog car le produit ne va pas se fabriquer comme il faut tout seul, mais également auprès du management qui ne manquera pas d’avoir toutes sortes de désidératas auxquels il faudra répondre favorablement ou non, mais toujours de façon argumentée.

Si Takeuchi et Nonaka avaient théorisé le rôle de Product Owner en 1986, ils l’auraient probablement rendu garant de la liberté d’approche dans le développement du produit, du choix de ses orientations, ainsi probablement que d’une partie du travail d’orchestration qui consiste à embarquer les différentes parties prenantes et compétences dans la danse des sprints.

Malheureusement, le PO est souvent la première victime de cette volonté des organisations à plier le paradigme agile à leur façon historique de fonctionner. Ce qui devait être à la base un démultiplicateur de la valeur créée par l’équipe produit est devenu un édulcorant du chef de projet, trop poussiéreux pour faire partie de la nouvelle vague agile.

Et comme cette nouvelle vague s’accompagne d’une myriade de nouveaux outils et façons de formaliser les choses, c’est assez naturellement que le PO s’est vu confier le brassage d’une montagne de tickets Jira, la rédaction des User Stories et autres joyeusetés qui cantonnent le PO à un rôle qui n’est pas tout à fait le sien.

Comprenons-nous bien : rédiger des US n’est pas inutile. Mais cela reste le livrable du PO, la partie émergée de l’iceberg. La plus grande partie de son temps, le PO la consacre au travail nécessaire pour pouvoir rédiger des US intelligentes et réellement utiles pour le client. Quant à la gestion des lots de travail, tickets Jira et autres, il est utile de rappeler que le Product Owner n’a pas pour vocation de vérifier que l’équipe crée bien le Produit que d’autres ont imaginés, mais bel et bien d’alimenter l’équipe avec des orientations et des priorités pour lui permettre de fabriquer le bon produit.

Ainsi, le PO a un rôle de guide, bien plus qu’un rôle de chef de projet.

Ce rôle qui doit être le sien implique de faire tout un tas de choses que le PO dévoyé n’a pas le temps de gérer, car trop occupé à jouer le chef d’orchestre et à reporter aux multiples COPIL, COSUI, CODIR et autres « CO » qui peuplent les agendas (1h pour participer, 2 jours pour s’en remettre comme dirait l’autre).

Parmi les responsabilités qui passent à la trappe, le contact direct et au quotidien avec le client est probablement la plus importante de toutes.

Le Seigneur des PO

Connaissez-vous les AMAP ?

Les Associations pour le Maintien de l’Agriculture Paysanne sont des entités qui mettent en relation des consommateurs avec des producteurs de fruits, de légumes, d’œufs, de lait et de viande. L’objectif étant d’éliminer tous les intermédiaires entre le producteur et l’assiette du gourmet. Les avantages sont multiples : des produits frais récoltés le matin, tout ce qui est produit est consommé, une traçabilité parfaite du produit, une rémunération plus juste pour le producteur, une consommation locale en accord avec les saisons et par conséquent plus écologique.

En d’autres termes : on limite le nombre d’intermédiaires pour assurer une meilleure transmission de la valeur du produit alimentaire.

Une équipe Produit, c’est un peu l’AMAP du monde de l’entreprise : il faut éliminer les intermédiaires entre le Client et « ceux qui font » pour permettre à ces derniers de mieux comprendre comment le Produit est utilisé (et donc de mieux faire), et à ceux qui utilisent le Produit de mieux comprendre comment il est fait (et donc de mieux l’utiliser). Tout le monde y gagne.

Le Product Owner ayant comme responsabilité de guider l’équipe dans sa fabrication du bon produit, c’est tout naturellement que la connaissance approfondie de son client, ses habitudes, son environnement et ses problèmes, fait partie de son devoir quotidien. C’est simple : quand il n’est pas en train de tripatouiller son backlog, de regarder ses KPI produit, ou de discuter avec son équipe de la valeur métier de telle ou telle fonctionnalité, le PO doit être en train d’écouter ses clients.

La façon dont le PO s’acquitte de cette tâche dépend bien entendu de tout un tas de facteurs : la nature du produit, de ses utilisateurs, l’activité de l’entreprise, le contexte actuel, le type de produit concerné, l’âge du capitaine… On pourra tout de même citer quelques grands classiques comme l’interview, la revue de commentaires et d’avis en ligne, écumer les forums et les communautés d’utilisateurs si elles existent, et les divers ateliers collaboratifs style « Focus Group » ou « Buy a Feature ». Tout cela, le PO peut le faire seul pour le restituer, ou emmener ses copains de l’équipe pour qu’ils puissent se rendre compte par eux-mêmes de la façon dont les « vraies personnes » utilisent leur produit (le fameux « pousser les ingénieurs à sortir du bureau pour aller sur le terrain » de Takeuchi et Nonaka).

Tout ceci prend du temps. Beaucoup de temps. Et du temps, le Product Owner en manque, car il est considéré comme un chef de projet et qu’il évolue dans une organisation qui la plupart du temps considère que boire des canons avec les utilisateurs ne fait pas partie de son travail.

Mais je suis taquin. La réalité est plus complexe. C’est « systémique », dira le consultant.

Parmi les raisons qui font que le PO ne va pas assez au contact du client, on peut citer les suivantes :

• Il n’a pas le temps. Tout simplement. Coincé entre le management d’une constellation de parties prenantes (et d’ailleurs souvent des interlocuteurs « métier » qui transmettent au PO leurs désidératas pour le produit), la gestion de son équipe, la vie de l’équipe Scrum qu’on lui demande souvent (à tort) de gérer… Le PO recherche l’oxygène tel un poisson hors de l’eau. Parfois, le PO « Owne » plusieurs produits, ce qui n’arrange pas ses affaires.
• Il ne sait pas faire, ou ne sait plus faire. Car il est loin le temps de la formation. A force de débiter mécaniquement de l’US et de calculer des « value score » avec des formules ésotériques, le PO a oublié comment sonder la tête du client pour capter la matière première de tout backlog qui se respecte.
• Il ne se sent pas légitime. Car la connaissance du client est le pré carré d’une instance dédiée : direction de la « Customer Experience », service client, équipes commerciales, guilde UX, direction métier…. Le PO est comme tout le monde : il a besoin de vivre sereinement sa journée de travail, donc il n’insiste pas.
• Quelque chose s’est brisé entre lui et son équipe. Parce qu’à force d’endosser le rôle de (micro-)manager, le PO est vu comme un enquiquineur en chef, et la communication avec « ceux qui font » passe mal. Du coup, soit le PO passe beaucoup de temps à construire une relation de confiance avec l’équipe, soit il finit par faire cavalier seul.

C’est un cercle vicieux dont il est particulièrement compliqué de s’échapper : le Product Owner n’est pas considéré comme il devrait l’être, l’équipe n’a pas la liberté de décision qu’elle devrait avoir, donc le PO ne peut pas faire le boulot qui devrait être le sien, donc il n’est pas considéré comme tel….

La grande perdante, c’est votre entreprise.

Car cette distance entre les clients et l’équipe produit rend nécessaire un échange d’informations permanent entre « ceux qui font » et « ceux qui connaissent le client ». Donc dilution, perte de qualité, préoccupations différentes, et risque accru de développer un produit qui n’est pas le bon. Sans compter toutes les instances nécessaires pour contrôler le tout, et dont une organisation vraiment agile se passerait bien puisque l’objectif est justement de dégraisser le mammouth pour prendre des décisions plus rapides et plus pertinentes.

Malgré tous vos efforts, votre organisation ne sera pas vraiment agile tant que vous ne rendrez pas à vos Product Owners leur capacité à rencontrer au quotidien le client pour se donner les moyens de faire des arbitrages produit pertinents.

L’interview de Nathalie Keo – Product Owner – Biogen

La définition du rôle de Product Owner varie beaucoup en fonction des entreprises. Dans bon nombre d’entre elles le rôle est hélas souvent associé à celui de chef de projet, avec une lettre de mission qui consiste à veiller à ce que l’équipe développe bien dans le temps ce qui est prévu par d’autres. Ce n’est bien sûr pas un mauvais rôle, mais ce n’est pas ce qu’un PO devait faire.

Au cours de mes diverses expériences, j’ai eu la chance de bénéficier d’une grande liberté d’action-décision qui m’a permis de pousser à fond mon rôle de Product Owner, d’être véritablement responsable de mes produits, et de mener des démarches qui échappent traditionnellement aux PO comme la rencontre directe des clients.

Chez France Télévision, je travaillais sur l’application de programme pour enfants Zouzous et Ludo, qui s’appelle aujourd’hui Okoo. Nous ne pouvions pas nous appuyer sur une équipe de service client, et nous avions donc accès directement aux utilisateurs finaux qui étaient aussi bien les enfants que leurs parents. Les réseaux sociaux et les différents stores sont un excellent moyen de garder le contact au quotidien et de créer un lien de proximité accessible. En plus de l’intérêt certain pour l’évolution du produit, le contact utilisateurs via les réseaux sociaux a l’effet positif de les transformer en ambassadeurs du produit. En plus de ce contact « distant », nous avons à quelques occasions fait venir des enfants dans nos locaux pour mener des tests sur certaines fonctionnalités de l’application. Nous avons également eu la chance de pouvoir faire des tests avec une psychologue spécialiste de l’enfant, afin de comprendre son comportement et son besoin surtout quand il n’est pas en âge de formuler un raisonnement. C’est un bon moyen de connaitre les motivations et craintes des parents, pour pouvoir les retranscrire dans l’app de manière sécurisée.

Dans la startup Kolibree, en partenariat avec Colgate-Palmolive, nous développions une brosse à dents intelligente associée à une application de jeu en réalité augmentée pour apprendre aux enfants à bien se brosser les dents. Pour alimenter notre algorithme et bâtir l’expérience de notre application, nous avions un besoin vital de pouvoir observer et interagir avec des enfants en apprentissage du brossage de dents. Pendant longtemps notre travail a souffert de ne pas pouvoir être mené en lien étroit avec les utilisateurs. Avec le COVID, nous avons eu les coudées franches pour construire un panel d’utilisateurs à distance. Avec l’aide de cet outil, et en travaillant en bonne intelligence avec notre partenaire nous avons finalement pu nous alimenter de cette connaissance directe des utilisateurs qui nous manquait.

Chez Biogen, je suis Product Owner sur Cleo : une application qui accompagne les patients atteints de la sclérose en plaque dans la gestion de leur quotidien. Elle leur communique des informations sur la maladie, les aide à préparer leurs rendez-vous avec le neurologue, leur propose des activités à réaliser en fonction de leur condition physique. Dans le milieu médical, il est naturel que le dialogue avec le patient soit très encadré et très codifié. Mais ça ne nous empêche pas d’être en contact direct permanent avec nos utilisateurs pour comprendre leurs problèmes et la façon dont ils gèrent la maladie. La différence avec une entreprise « classique » est que chaque entretien, chaque atelier, est soigneusement préparé en amont avec le service juridique. Le rythme de développement est plus lent, mais nous sommes très autonomes dans les choix que nous faisons car l’entreprise tout entière met les moyens pour que nous puissions mener notre travail jusqu’au bout, dans les règles de l’art.

Selon les organisations, le Product Owner est plus ou moins autonome dans le choix des orientations de son produit. Mais qu’il le soit totalement ou non, cela ne change rien au fait qu’un PO doit pouvoir comprendre parfaitement comprendre le cœur du problème qu’il est en train de résoudre pour ses utilisateurs.

Quel que soit son environnement de travail, une part importante du rôle de PO reste la démarche de connaissance directe du client, seul ou avec des personnes aidantes, mais jamais par procuration.

50 Shades of PO

Finalement, il y a autant de Product Owners qu’il y a de produits et d’entreprises.

Et s’il existe de nombreuses façons pour un PO de bien effectuer son travail, la définition du travail, elle, est toujours la même :

Dans un article publié sur le blog de Scrum, Robbin Schuurman partage une classification des Product Owner que j’aime beaucoup, partant du principe que plus un PO est libre de faire son boulot à fond, plus il passe d’une posture de simple receveur à une posture d’initiateur. Entre les deux extrêmes : plusieurs niveaux que Schuurman définit ainsi :

• Scribe: le PO se contente de rédiger sous forme de User Stories des spécifications que d’autres personnes lui transmettent. Il « pisse de l’US » au même titre que des développeurs mal considérés « pissent du code ».
• Proxy: pareil que Scribe, mais avec un tout petit peu plus de pouvoir de suggestion, notamment dans l’organisation des priorités du backlog. Mais en fin de compte, le « Proxy PO » n’a aucun pouvoir de décision.
• Business Representative: à ce stade, le PO est le pendant des métiers au sein de l’équipe. Logiquement, il connait donc bien les besoins et les utilisateurs (ou du moins, pense bien les connaître) et est capable de piloter son backlog si on lui en laisse le loisir. Il dépend toutefois d’un certain nombre de contraintes, et doit s’aligner sur des directives qui ne sont pas les siennes, en particulier le budget et les orientations stratégiques du projet. Si le PO « Business Representative » dispose d’une vraie liberté de rencontrer ses utilisateurs au quotidien, il peut commencer à faire du bon boulot. S’il n’est que le relais d’une direction métier tapie quelque part derrière lui, c’est plus gênant.
• Sponsor: même chose que le Business Representative, mais avec une liberté dans la gestion de son budget en plus. Le « PO Sponsor » peut ainsi être beaucoup plus agile que son petit frère lorsqu’il est nécessaire d’augmenter ou de réduire la voilure sur le développement de tel ou tel aspect du projet. Pour illustrer les bienfaits d’un pilotage budgétaire « orienté terrain », Bjarte Bogsnes dans sa théorie du Beyond Budgeting utilise le parallèle entre le feu rouge et le rond-point. Ce dernier confie la gestion temps réel de la circulation et des microdécisions qui y sont associées aux automobilistes eux-mêmes. Alors que le feu rouge obéit à une loi qui est définie par des personnes qui sont loin du terrain, le rendant inefficace dans bon nombre de situations en plus de l’étude préalable nécessaire à sa mise en place.
• Entrepreneur: soit le stade ultime du rôle de PO (et ce qu’il devrait être partout pour coller aux principes fondamentaux de l’agilité). Le PO agit tel un « mini-CEO », définissant les objectifs stratégiques du projet, les priorités dans le développement, la valeur délivrée aux utilisateurs, son budget… Ce qui ne le dispense pas de communiquer le pourquoi du comment de ses choix à ses supérieurs hiérarchiques, comme le ferait un vrai CEO auprès de ses investisseurs et partenaires.

Dans la course à l’adoption de l’agilité, il peut sembler légitime de commencer par le bas et de faire évoluer l