En finir avec le Product Owner ?

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 :

rodina

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.

superman-standing

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.
maitrise-ouvrage

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

Note de lecture : The Joy of Patterns, par Brandon Goldfedder

Note : 3 ; Un workshop pour Design Patterns vraiment léger  !

Cet ouvrage est dans la même lignée que “Design Patterns Explained”. Ce livre aborde les patterns pour les nouveaux venus, mais avec perspicacité. Il mise beaucoup sur l’apprentissage par l’exemple et 3 gros exemples en Java, C++ et Visual basic y sont développés.

L’ouvrage débute par ce que sont les patterns, leur nature et leur structure, avec un petit détour vers les patterns language. Plus surprenant, le chapitre dédié aux concepts de base de l’orienté objet. Je pense que cibler les nouveaux venus à l’objet pour un ouvrage, même d’introduction, aux patterns est assez questionnable.

Globalement, même s’il est agréablement écrit, cet ouvrage est quand même un peu léger, avec ses 110 pages hors annexes (volumineuses, qui contiennent le code source), et même 65 pages si je ne compte que ce qui est vraiment le cœur du livre !

Du côté des bonnes nouvelles, le texte est concis et l’auteur excelle à expliquer ses raisonnements. Beaucoup de diagrammes UML émaillent l’ouvrage, en taille « pour aveugles » mais ils n’aident pas tellement à l’exception des quelques diagrammes de séquence qui sont bienvenus.

joy-of-patterns

Référence complète : The Joy of Patterns: Using Patterns for Enterprise Development – Brandon Goldfedder – Addison Wesley / Software Patterns Series 2001 – ISBN: 0-201-65759-7

The Joy of Patterns: Using Patterns for Enterprise Development


http://www.goodreads.com/book/add_to_books_widget_frame/0201657597?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Maîtrisez votre gestion de configuration logiciel, par Dominique Jacquin

Note : 2 ; Lourdingue !

Cet ouvrage ne vous aidera pas à comprendre ce qu’est la gestion de configuration. Pas vraiment, même si il prétend le faire. En fait le point focal de ce livre est l’aspect qualité, donc processus de la gestion de configuration. En principe, cela recouvre 3 thèmes : la gestion de version, la gestion de configuration et la gestion des changements. La gestion de version, et plus globalement la gestion des espaces de développement est appelée ici « gestion de la production » (on se demande bien pourquoi), et n’est traitée que succinctement. Ce sont les 2 autres thèmes qui constituent la matière première.

Franchement, si vous ne connaissez pas le sujet, vous serez perdus ! Le texte est une somme de descriptions prescriptives et n’est nullement explicatif (je n’évoque même pas les exemples de fin d’ouvrage, ils sont pathétiques). Quelques illustrations complètent le texte : des transparents Powerpoints tellement basiques et creux que l’on se croit revenus à l’école primaire, les diagramme SADT et les organigrammes sont aussi ennuyeux qu’on est en droit de l’escompter. Bref, on nous propose de faire des choses, on ne sait guère pourquoi, à croire que l’objectif de l’auteur était simplement de démontrer l’étendue de son savoir ! L’aspect normatif ISO 9000 et ISO 10000 est le seul aspect original (je n’ose dire intéressant) du texte. Il apparaît en fil rouge au fil de l’ouvrage et un chapitre spécifique lui est dédié. Je ne suis pas sûr que, même si la certification ISO vous intéresse, le livre vous soit d’un quelconque intérêt, mais je sais répondre par la négative dans le cas contraire ! Des plans types sont fournis en fin d’ouvrage et en complément de certains chapitres, ils ont l’intérêt d’être commentés. Sait-on jamais, cela peut servir.

Maitrisez votre gestion de configuration logicielle

Référence complète : Maîtrisez votre gestion de configuration logiciel, une étape pour la certification ISO 9000 – Dominique Jacquin – Masson 1996 – ISBN : 2-225-85424-6

Maîtrisez votre gestion de configuration logicielle

http://www.goodreads.com/book/add_to_books_widget_frame/2225854246?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

crookedindifference:

Rest in Peace, Neil Armstrong

Buzz Aldrin took this picture of Neil Armstrong in the cabin after the completion of the first EVA. This is the face of the first man to set foot on the Moon, just hours earlier, on July 20th, 1969.

Neil Armstrong was a quiet self-described nerdy engineer who became a global hero when as a steely-nerved pilot he made “one giant leap for mankind” with a small step on to the moon. The modest man who had people on Earth entranced and awed from almost a quarter million miles away has died. He was 82.

RIP Neil Armstrong. You’re part of the human kind history.