Nous nous retrouvons de nouveau pour le troisième volet de mon feuilleton de l’été. Après le roadmap et le backlog, occupons-nous un peu du Product Owner. Si vous discernez ma logique, vous devriez pouvoir deviner quel sera l’épisode suivant …

Je rappelle de nouveau mon mot d’avertissement : J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.

C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !

Product Owner qui es-tu ?

En passant en revue ce que dit la littérature, nous devons comprendre que le Product Owner est visionnaire, leader mais également berger de l’équipe (1) il est aussi responsable du ROI du projet (2). On lui attribue aussi la responsabilité du contenu du produit, donc les fonctionnalités subordonnées à la vision, de leur échelonnement dans le temps (qui conditionne le ROI) et des choix tactiques au jour le jour (3). Il est aussi le point de convergence aux autres acteurs de l’entreprise partie prenantes dans le projet (4)

Bref, le Product Owner doit plus ou moins ressembler à ça :

Product Owner, pourquoi es-tu là ?

Fondamentalement, Scrum a été pensé comme un processus de développement logiciel. Cela semble bien de prime abord : après tout, développer du logiciel, c’est notre boulot !

En pratique, Scrum a planté une clôture autour de l’équipe du développement (le “team”) et de son berger (le Scrum Master, on s’occupera de son cas dans un épisode ultérieur). La relation entre l’intérieur de la clôture et ce qu’il y a à l’extérieur est reporté  sur une personne unique qui s’occupera donc de tout le reste, à savoir ce qui n’est pas du développement.

Product Owner, es-tu Superman ?

A ce stade, vous pouvez déjà répondre à cette question en comparant votre PO à sa représentation picturale ci-dessous.

Pourquoi Superman ? Cessons d’occulter ce qui se passe derrière la barrière et tentons de dresser une liste de ce que le périmètre produit va représenter si l’on englobe non plus seulement le développement mais tout ce que va prendre en compte cette activité produit. Ma liste va être bien naïve, n’étant hélas pas un spécialiste de la question, disons que c’est juste pour amorcer la réflexion.

• Connaissance métier sur le périmètre couvert par le produit.
• Compréhension de la segmentation du marché selon différentes dimensions : maturité, domaine d’activité, profils d’utilisateurs.
• Stratégie de vente, de pénétration et de fidélisation, pour le volet commercial.
• Appréhension des différents facteurs de risques : volatilité et compréhension du marché, positionnement de la concurrence, incertitudes sur les facteurs internes et externes influençant le déroulement du marché.
• Connaissance des opportunités d’alliance, pour renforcer une position sur un marché (coalition), soit pour développer une “verticale”. Les options dégagées peuvent redessiner le contour fonctionnel du produit et/ou influer sur la priorité des différentes fonctionnalités.
• Maîtrise du modèle de cash-flow afin d’optimiser les revenus générés par le produit et/ou permettre la récurrence de ces revenus.

Vous pouvez ajouter vos propres points à cette liste déjà longue, mais on constate déjà que cela fait beaucoup. La plupart des entreprises l’ont d’ailleurs acté : elles placent derrière le PO non pas une mais plusieurs personnes pour couvrir ces différentes facettes. Mais du point de vue de l’équipe située dans l’enclos, on ne veut pas trop le savoir : on ne veut voir qu’une seule tête.

A défaut d’être un Superman, le PO sera donc un “hub”. Cette capacité à être un “hub” vient-elle naturellement avec la capacité visionnaire dont nous avons parlé plus haut ? Vous devinerez certainement ma région d’origine à ma réponse : peut-être bien que oui, peut-être bien que non …

Un des éléments que j’apprécie particulièrement dans les approches agiles, c’est l’effacement les responsabilités au sein de l’équipe. L’équipe est responsable de délivrer le produit. Cela requiert différentes compétences qui sont assurées par la complémentarité des membres de l’équipe, mais sans qu’il soit nécessaire de dresser des rôles. Plus simplement dit: c’est travailler en bonne intelligence. Curieusement, ce que l’on accepte et que l’on acte côté du côté de l’équipe de développement ne s’étend pas côté produit…

NOUS versus VOUS

Arrivé à ce point, j’en reviens à l’aspect que j’ai évoqué plus haut : il y a ce qui est dans l’équipe de développement et ce qui est en dehors. Et ce qui est en dehors se résume au Product Owner. Mais outre le fait d’occulté la complexité et les ramifications de ce rôle, l’autre effet collatéral malheureux est que si le Product Owner fait partie de Scrum, il ne fait pas partie de l’équipe !

Avez-vous déjà entendu le P.O. déclarer lors d’une démo : “vous avez fait du bon boulot” ? Beaucoup d’entre-vous répondrons oui, et penserons qu’ils ne voient pas le problème. Et il n’y a pas de problème apparent, l(intention est clairement bonne. Mais pourquoi diable ce PO ne se sentait pas partie prenante de cet effort ? Pourquoi n’a-t-il pas déclaré “nous avons fait du bon boulot” ou plus modestement “nous avons fait du boulot dont nous pouvons être fiers” ?

La réponse est qu’hélas Scrum ne nous aide pas ici. Si l’intention des créateurs de Scrum était et est toujours d’englober PO et équipe dans une même dynamique, cette séparation permet de retomber très facilement dans une logique de répartition des tâches, plutôt qu’une logique d’endossement d’un leadership. D’ailleurs à ma connaissance, rien dans Scrum ne dit que le PO et seul le PO doive maintenir le backlog. Rien ne dit non plus que l’équipe ne doive pas se sentir impliqué dans la qualité de celui-ci. Et je pourrais continuer longtemps. Pourtant il m’apparait qu’il est facile d’avoir cette lecture, et que de nombreuses équipes qui viennent d’anciens processus et font partie de “l’early majority” de la courbe de Moore pour l’adoption de Scrum penchent en ce sens. Je ne suis pas non plus certain que les consultants qui épaulent ces équipes les aident toujours dans la bonne direction …

J’en appelle maintenant à Gilles Mantel qui nous a bien dynamisé avec sa “Scrum Master Academy”: il est peut-être temps de s’attaquer aussi à une “Product Owner Academy” ! L’un des articles pourrait être “Product Owner, ta place est au milieu de l’équipe”.

Du Product Owner à la MOA

J’ai récemment lu un billet d’Audrey Pedro à propos du rôle de “Product Owner Proxy” qui faisait écho au billet de Claude Aubry sur le même thème allant dans l’autre sens. Qui a raison, que penser ?

Je trouve intéressant cette émergence du concept de “Product Owner Proxy”. Non que je lui donne raison, et je penche là dans le sens de Claude, mais parce que je pense qu’il est la réponse à la légèreté avec laquelle Scrum appréhende ce rôle qui est, je le répète ici un peu différemment : tout ce qui n’est pas lié au développement va dans l’escarcelle du PO. C’est à la fois trop pour un seul homme (ou une seule femme) et une incitation à retomber dans de vieux réflexes contre lesquels la communauté agile s’est battu pendant des années: le partitionnement en rôles.

Le Product Owner Proxy est ni plus ni moins que la résurgence du concept de MOA : un intermédiaire, avec des compétences n’existant pas dans l’équipe de développement, mais qui n’est pas le “sachant” métier et doit se retourner vers ce référent métier (le vrai PO) pour avoir des réponses ! Nous avons là une belle équation perdant-perdant:

• L’équipe n’a plus accès au référent métier capable non seulement de lui transmettre ses besoins, mais une appréhension de son métier qui passe par des remarques, des discussions informelles et toutes sortes d’éléments intangibles qui ne sont perceptibles que par le contact direct
• L’équipe perd la responsabilité de la compréhension du fonctionnel car c’est le P.O. proxy qui fait cela. Elle se replie sur le développement et fait … ce qu’on lui dit de faire. Vous pouvez coller le vocable que vous voulez, mais j’estime qu’ici on n’est déjà plus dans un projet agile, car l’état d’esprit n’y est plus.
• Si par hasard l’équipe vient à dialoguer directement, c’est cette fois le P.O. proxy qui voit échapper une partie de la compréhension du besoin … et risque de se retrouver sur le bord de la route.
• Il faut bien sûr pour compléter cette évocation parler du Product Owner qui perd le contact quotidien avec l’équipe, voir avec la réalité du développement et va établir une relation “moi / vous” avec l’équipe, comme je l’ai évoqué plus haut.

Après avoir donné raison à Claude, donnons aussi raison à Audrey ! Audrey définit avec justesse les missions qu’elle remplit. Cela signifie qu’il y a du boulot à faire, aucun doute. Et s’il y a du travail à faire pour épauler la vision du P.O., il doit être fait. Mais pas en créant un nouveau rôle accentuant une vision du développement en silo qui n’a rien à faire dans une approche agile, mais en intégrant cette personne à l’équipe de développement !

Une seule équipe

Là où j’entends parler de rôle, je voudrais parler de compétences ! Plutôt que de raisonner sur la base d’attribution de tâches liées aux rôles, acceptons l’idée que nous avons besoin d’un ensemble de compétences (développement, test, architecture, ergonomie, mais aussi compréhension du besoin, marketing, etc…) pour couvrir tout ce qu’il y a à réaliser. Cela nous amène vers plusieurs conséquences, que je vais illustrer en faisant d’Audrey ma “persona” (bien que je ne la connaisse pas) :

• Audrey n’a plus une étiquette particulière. Elle est intégrée à l’équipe. Elle n’est plus nécessairement la seule à accomplir les tâches qu’elle a décrite, bien que ses connaissances lui confèrent un leadership sur ces parties. Mais c’est un leadership lié aux compétences, non au fait qu’elle soit dépositaire d’un rôle.
• Intégrée à l’équipe, elle embrasse non plus l’étroite mission du P.O. proxy, mais l’objectif de l’équipe: délivrer un produit. Elle est prête à intervenir plus largement, sur des aspects qu’elle connait moins et où elle n’aura pas le leadership: ergonomie, tests fonctionnels, etc… L’acquisition de ces nouvelles compétences lui ouvrira de nouvelles perspectives vers le futur, mais surtout elle va se montrer plus polyvalente sur le projet actuel.
• J’ai parlé de l’objectif de l’équipe : délivrer un produit. Et j’ai certainement tord. Nous venons de redessiner le contour d’une équipe plus large incluant le P.O. proxy, mais aussi le P.O. ! L’objectif de l’équipe n’est plus alors de livrer un produit mais de rendre un service. Le succès du projet n’est plus la livraison du produit mais l’accomplissement de l’objectif business initial du projet. La construction du produit y est incluse. L’équipe élargie fait bloc derrière cet objectif business et cesse de limiter son horizon à la construction du produit.

Dans son billet, Audrey parle d’assurer la sérénité de l’équipe. Si l’on parle d’éviter les perturbations qui gênent l’avancement du projet, alors je suis d’accord. Mais si l’on parle d’isoler l’équipe des réflexions et questionnements fonctionnels, je ne le suis pas. Le rôle d’une équipe agile est d’être au front, au contact avec les problématiques métier. C’est vrai que c’est moins confortable que de travailler sur l’intégration de la librairie machin-bidule. Mais c’est de ce contact qui naissent la richesse et les solutions innovantes.

Justement, en parlant d’innovation.

Lean Startup

Le courant du Lean Startup illustre parfaitement ce mode de pensée: le processus est complètement orienté, non plus même sur la valeur délivrée au client, mais vers sa compréhension et l’apprentissage de l’impact de ce que nous faisons sur celui-ci. De facto, l’équipe englobe la totalité des personnes qui vont assurer cette mission. L’un des points du livre qui m’a interpellé à postériori, c’est qu’à aucun moment Eric Ries n’évoque la notion de “rôle”. Vous n’en trouverez même pas l’entrée dans l’index de fin.

Quelle solution ?

Dans mon esprit, Scrum a définit le Product Owner comme le dépositaire de la direction à emprunter. Peut-être l’appellation “propriétaire” induit-elle un biais malheureux : elle incite les autres acteurs du projet à abdiquer une participation active à la compréhension et à la définition du besoin.

Personnellement, je n’ai jamais vu de projet sur lequel il n’y avait pas un initiateur, une personne “portant” l’idée. Parfois cette personne disparait derrière la lourdeur des structures ou la “culture du comité”. Mais c’est cette personne qui est pour moi le P.O. Elle n’a pas toujours les qualités de superman évoquées plus haut mais cela ne devrait pas être prépondérant, par exemple en suivant les lignes directrices esquissées plus haut:

• Il n’y a qu’une équipe et elle englobe tout le monde y compris le Product Owner.
• La réussite de l’objectif business (et non uniquement la construction du produit) est l’affaire de tous. Tout le monde doit se sentir concerné et tout le monde peut contribuer.
• Jetez aux orties les abaques d’affectation de types de tâches en fonction des rôles.

Et vous, quelle est votre vision du Product Owner ?

Références

(1) Agile Product Management with Scrum ; Roman Pichler ; Addison Wesley 2010 ; p. 4

(2) Agile Project Management with Scrum ; Ken Schwaber ; Microsoft Press 2004 ; p. 20

(3) Scrum Le guide pratique de la méthode agile la plus populaire 2nd édition ; Claude Aubry ; Dunod 2011 ; p. 30

(4) The Scrum Field Guide ; Mitch Lacey ; Addison Wesley 2012 ; p. 72