Série - Product Owner

Fil des billets - Fil des commentaires

Le rôle de directeur de produit

Un résumé du rôle, appelé Product Owner dans Scrum et Customer dans XP

Le directeur de produit [1] est le représentant du "métier" dans le projet.

Responsabilité

En tant que représentant des clients et utilisateurs, il est responsable de définir les caractéristiques du produit développé par l'équipe, en termes de :

  • fonctionnalités offertes. Plus précisément, il identifie chaque exigence que doit satisfaire le produit et la collecte comme élément du backlog de produit (ou item de backlog). Il fournit les détails sur ces éléments quand c'est nécessaire pour l'équipe. Il est souhaitable qu'il spécifie les tests d'acceptation-acceptance tests- de chacun.
  • priorité. C'est lui qui définit l'ordre dans lequel ces éléments seront développés en fonction de la valeur qu'ils apportent aux clients et utilisateurs. Cela permet d'alimenter l'équipe avec un backlog de produit prêt pour la planification des sprints,
  • but. C'est lui qui définit l'objectif d'une release et qui prend les décisions concernant le planning de la release.

dp.jpg

Compétences

Une personne qui joue ce rôle devrait posséder les compétences suivantes :

  • bonne connaissance du domaine métier,
  • capacité à avoir une position respectée par tous les intervenants extérieurs (clients et utilisateurs),
  • capacité à prendre une décision au bon moment (pas trop tôt ni trop tard),
  • esprit ouvert au changement,
  • facilité à communiquer avec l'équipe.

Quelqu'un qui a été Analyste Métier (Business Analyst) est un bon candidat pour ce rôle.

Affectation

Il n'y a qu'une seule personne qui joue ce rôle. Cette personne doit être affectée au projet : elle fait partie de l'équipe étendue et participe aux réunions. Le travail nécessite une affectation à plein temps ou presque.

Il est important qu'il soit très disponible pour répondre aux questions de l'équipe, pour définir les tests fonctionnels et donner son avis sur divers aspects du produit (l'interface homme machine d'un logiciel, par exemple).

Point clé

Son implication est capitale pour assurer le succès du projet. En définissant sa vision sur le produit, il donne l'impulsion à l'équipe. En promouvant à l'extérieur le résultat de chaque sprint, il fournit à l'équipe une reconnaissance qui la motive.

Notes

[1] j'utilise le terme depuis ce billet

Le Super Product Owner

Le responsable d'un groupe de Product Owners

Dans le billet Scrum structure les équipes, j'avais présenté l'exemple d'une organisation où la mise en œuvre de Scrum conduisait à modifier la façon dont les personnes participaient à des projets.

Avec l'objectif d'aller, avec Scrum, vers moins de multi-projets pour limiter les perturbations, nous étions arrivés à la notion de plateforme, qui fédère des applications, sur laquelle travaille une équipe. et pour laquelle les choses à faire sont dans un seul backlog :

Une plateforme, un backlog, une équipe

Quid du rôle de Product Owner ?

Pour chaque application de la plateforme, il existe une personne qui est en responsable. Cette personne, qui représente le client dans l'équipe, joue le rôle de Product Owner de l'application. Avec plusieurs applications chacune ayant son PO, on aurait donc :

Un backlog, plusieurs PO

Le problème d'avoir un groupe de PO, c'est que la responsabilité ne réside plus dans une seule personne. Or c'est justement pour éviter les inconvénients dus aux conflits à cause d'intérêts contradictoires, aux décisions ralenties, aux difficultés à prioriser, que Scrum recommande une seule personne pour le rôle de Product Owner. Comme dit Ken Schwaber :

Le PO est une personne, pas un comité

Comment avoir une équipe de PO tout en suivant ce conseil ? En ayant dans l'équipe une personne qui est un Super Product Owner[1]. Le SPO est là pour donner la vision globale et pour arbitrer.

A partir de ces idées, voilà ce qui a été envisagé pour l'organisation en question :

  • le rôle de SPO serait joué par une personne connaissant très bien la plateforme et l'équipe de PO contiendrait 2 ou 3 autres PO
  • un seul backlog pour la plateforme
  • dans la mesure du possible, un sprint est dédié à une seule application et le PO qui la gère s'implique plus pendant ce sprint
  • comme il y a 2 plateformes et donc 2 équipes, les sprints sont synchronisés pour simplifier la vie d'une personne faisant partie des 2 équipes.

Notes

[1] Mike Cohn parle de Chief Product Owner

Le Product Owner bichonne son backlog

Le backlog de produit demande des soins attentifs et réguliers !

J'ai passé une bonne partie de ma dernière semaine sur le backlog d'IceScrum. En tant que Product Owner de ce bel outil qui rencontre de plus en plus de succès, j'ai du travail qui va aussi en s'amplifiant. Le temps que je consacre à IceScrum peut être divisé en 3 parties à peu près égales :

Communiquer avec les utilisateurs

Il s'agit de travaux qui ne sont pas directement liés au développement du produit mais qui sont absolument nécessaires pour un Product Owner. IceScrum est un produit Open Source qui a de nombreux utilisateurs inconnus, mais aussi quelques uns que je connais bien et dont je sollicite régulièrement le feedback sur le produit. Il y aussi les 30 utilisateurs (étudiants et enseignants) de l'IUP ISI avec lesquels j'ai des relations privilégiées. Je fais aussi du marketing, des démos...

Travailler avec l'équipe sur le sprint courant

Je participe aux réunions du cérémonial avec l'équipe. A côté, je réponds aux questions sur les stories qui font l'objet du sprint courant. Au moins deux fois par semaine, je télécharge le build à partir du serveur d'intégration continue Hudson pour tester les stories et vérifier si elles sont bien finies. Je mets à jour les informations dans le suivi avec IceScrum (on peut y montrer le résultat des tests et déclarer une story comme finie).

Anticiper sur les sprints suivants

C'est dans cette partie que je bichonne particulièrement le backlog. Il faut ajouter dans le backlog ce qui remonte du feedback des utilisateurs, après s'être assuré de son intérêt, définir le type de story, formuler la story. Evidemment j'utilise IceScrum pour ça et une nouvelle story se place automatiquement au fond du backlog. Il faut ensuite se poser la question de la priorité de la story et, selon, la remonter dans la liste (un glisser-déplacer avec IceScrum).
Il est bien plus difficile de définir les priorités sur un produit qui a déjà une longue existence comme IceScrum que pour un nouveau développement. Quand on développe un nouveau produit, les priorités sont définies au niveau des features qui sont ensuite déclinées en stories qui conservent l'ordre défini pour les features. Avec un produit qui offre déjà de nombreuses fonctions et qui est largement utilisé, les nouvelles stories qui proviennent du feedback et aussi celles déclinées de la vision sont bien plus disparates, rendant la définition des priorités plus difficile à établir.
Une fois les 20 stories les plus prioritaires à peu prés identifiées, il faut aller voir l'équipe pour obtenir une estimation (avec un petit planning poker) pour les stories qui n'en ont pas encore. L'estimation de la taille m'amène souvent à ajuster les priorités. Cette réunion s'appelle en fait planification de release[1] : après avoir estimé, on associe les stories les plus prioritaires au sprint à venir, et éventuellement au suivant, pour avoir un horizon à un mois[2].
Avant la fin du sprint, il faut aussi élaborer les tests d'acceptation des 2-3 stories les plus prioritaires du prochain sprint.

Bref bichonner son backlog de produit pour qu'il soit prêt pour le sprint qui va commencer.

Notes

[1] j'appelais cela revue de backlog auparavant

[2] nos sprints durent deux semaines

L'intégration continue du point de vue du Product Owner

Pendant des années, j'ai attendu des versions de produit.

Elles devaient m'être envoyées par les équipes de développement pour que je les utilise ou pour que je les teste. Souvent j'ai attendu longtemps des versions qui ne venaient pas, je les ai réclamées. J'arrivais péniblement à avoir une livraison par itération, qu'on m'envoyait par mail ou qu'il fallait aller chercher par FTP. Pas pratique, pas satisfaisant.

Maintenant, avec l'intégration continue, c'est bien plus confortable pour les Product Owners. J'en entends de plus en plus dire tout l'avantage qu'ils en tirent, comme lors des retours d'expérience du dernier SigmaT.

Sur le projet IceScrum nous avons un serveur d'intégration continue avec Hudson. Nous avons programmé un nighty build tous les jours toutes les nuits et il est possible de lancer un build à tout moment. Pendant plusieurs mois, je me suis donc connecté sur Hudson le matin pour vérifier si un nouveau build avait été produit. Après je faisais les manipulations suivantes :

  • téléchargement du war
  • arrêt de mon serveur Tomcat local
  • suppression de l'ancien war et du répertoire icescrum2 dans webapps
  • copie du nouveau war dans webapps
  • relance du Tomcat
  • lancement d'IceScrum

Et là j'étais content, je pouvais accéder aux nouveautés et les tester. Mais ça me prenait quelques minutes pour faire tout ça. Maintenant c'est encore mieux, nous avons un déploiement automatique du dernier war sur un serveur de test, je n'ai plus qu'à me connecter dessus pour tester.

Comme je m'intéresse aussi à la qualité du code, je trouve très utile l'alimentation de Sonar à chaque build pour mettre à jour les rapports produits par ce bel outil.

On s'habitue vite et ces jours-ci, je suis un peu frustré : d'abord nous avons eu un build en échec et surtout le rythme de production a diminué parce qu'une bonne partie de l'équipe est en examen. L'intégration continue, qui est présentée comme une pratique d'ingénierie, est aussi une pratique qui contribue à renforcer la collaboration entre le Product Owner et le reste de l'équipe.

Le rôle de Product Owner

Un des mes premiers billets, il y a plus de 4 ans, portait sur le rôle du Product Owner.

Mais à l'époque, dans une volonté d'utiliser le français, je parlais de directeur de produit. Finalement ça n'a pas collé et j'ai repris le terme anglais, en le prononçant à la française (produktoneur).

Le Product Owner est un rôle clé dans la mise en place de Scrum. Comme on me pose de plus en plus souvent des questions[1] sur comment tenir ce rôle, voici quelques billets s'y rapportant :

Note

[1] on m'a même demandé une grille de salaire... Après enquête, un PO est plutôt bien payé.

Le PO proxy n'existe pas

J'ai participé vendredi à une réunion/débat organisée par l'association Agile Toulouse sur le rôle de PO, axée sur la notion de PO Proxy[1].

Note

[1] Ce billet n'est pas un compte-rendu de la réunion, j'y présente mon point de vue.

Nathalie, dont c'était la fête, nous a fait une présentation de pratiques pour lesquelles le PO pouvait être assisté, par exemple pour l'animation d'ateliers de type Innovation Games.

De mon côté, j'avais préparé une carte heuristique centrée sur le rôle de Product Owner :

Product_Owner.png

C'est un résumé, tiré du chapitre 3 de mon livre, qui présente :

  • ses responsabilités,
  • sa participation aux activités faites en collaboration par l'équipe,
  • les compétences souhaitées et
  • des conseils pour progresser.

PO est un rôle. Il est, en principe, tenu par une seule personne qui aura ces responsabilités et participera à ces activités. Il existe des situations où une seule personne ne sera pas en mesure d'y parvenir. Les 2 principales raisons sont le manque de compétence et le manque de temps. A noter que ce sont des situations temporaires, on peut acquérir des compétences et s'arranger pour avoir du temps.

On peut donc envisager qu'il y ait plusieurs personnes qui jouent le rôle de PO dans une équipe[1].

Voyons quelques cas :

  • une personne novice se fait assister par un coach, qui l'aide à tenir ses responsabilités et à animer des ateliers et réunions,
  • deux personnes se partagent des domaines fonctionnels,
  • il y a une personne pour le remplacement au cas où (backup).

Pour que ça fonctionne bien, il convient d'être clair sur deux responsabilités clés : prioriser les stories et déclarer les stories finies ; il faut aussi assurer la participation aux réunions d'équipe.

Quand une seule personne joue le rôle de PO, il peut déléguer certaines responsabilités à des membres de l'équipe, par exemple sur les critères et tests d'acceptation.

Par contre si une personne délègue la plupart des responsabilités, en particulier la priorisation et la finition des stories, et ne participe pas à la majorité des réunions, on ne peut plus considérer qu'elle soit PO. C'est celui qui reçoit la délégation et participe au travail collaboratif qui est le PO. C'est pourquoi le rôle de substitution présenté sous le nom de PO proxy n'existe pas.

Note

[1] Dans iceScrum, c'est une évolution qui s'est faite il y a quelque temps, alors que dans les premières versions une seule personne pouvait tenir le rôle.

Chapitre trois

Dans la série Suppléments en ligne, voici le Product Owner.

Pendant les vacances, j'ai commencé une série de billets visant à apporter des informations additionnelles aux lecteurs de mon livre Scrum. Après le premier chapitre, le chapitre deux, voici le chapitre trois.

Ce chapitre est le premier que j'ai vraiment écrit. C'était en juin 2009. J'avais déjà publié plus de 500 billets de blog à l'époque, dont un nombre significatif évoquaient le Product Owner. J'avais commencé par ce chapitre parce que le PO était un sujet que j'estimais bien maîtriser. J'espérais vaguement réaliser mon livre en compilant des billets déjà écrits. Je me suis vite rendu compte que ça ne se passerait pas aussi facilement...

Structure du chapitre

Voici le plan de ce chapitre sur le Product Owner (clic pour agrandir).

Le Product Owner

Le résumé en fin de chapitre

Dans une équipe Scrum qui développe un produit, le Product Owner est le responsable du résultat auprès des parties prenantes. Il apporte sa vision à l’équipe et définit les priorités de façon à obtenir un produit apportant le maximum de valeur.

L’implication d’un bon Product Owner est capitale pour assurer le succès du projet. En définissant sa vision sur le produit, il donne l’impulsion à l’équipe. En faisant la promotion du résultat de chaque sprint auprès des utilisateurs, il fournit à l’équipe une reconnaissance qui la motive. En collaborant avec l’équipe, il fait converger les énergies pour maximiser la valeur ajoutée au produit.

Changements dans les éditions successives

Ce chapitre n'a pas énormément évolué depuis la première édition. Il fait toujours environ 15 pages.

Sur les sujets à discussion à propos du Product Owner, j'avais déjà pris le parti de présenter le PO comme membre de l'équipe, participant aux scrums quotidiens et s'impliquant avec les développeurs pour finir les stories pendant le sprint.

Dans l'édition trois, j'apporte des précisions sur son implication pendant le sprint (et avant le sprint aussi, j'y reviendrai dans le chapitre cinq sur le backlog). Le guide Scrum 2013 n'érige pas en règle la participation du Product Owner au scrum quotidien.

Ma position, celle que je défends dans le livre, est qu'il est souhaitable que la personne qui joue le rôle de Product Owner soit également membre de l'équipe de développement et cela en fait un participant à la réunion quotidienne.

Liens cités dans le chapitre

Dans mon livre, les liens apparaissent souvent dans les notes de bas de page. Dans la version numérique, ils sont cliquables. Je les présente ici pour faciliter l'accès à ceux qui ont la version papier.

Autres lectures en relation

Errata

Rien pour l'instant.

Une journée de Product Owner

Dans l'édition 4 de mon livre, j'ai ajouté des descriptifs d'une journée typique d'un ScrumMaster et d'un Product Owner.

Après Nicolas, le ScrumMaster chez Peetic, c'est le tour de Céline, la productoneuse.

Voici l'extrait tiré du chapitre 4 Le rôle du Product Owner[1] . J'y ai ajouté, pour ce billet, des notes qui renvoient aux pratiques évoquées.


Céline tient le rôle de Product Owner de l’équipe Peetic.

Collaborer avec l’équipe

En tant que PO, Céline n’est pas simplement le représentant des clients et des utilisateurs dans l’équipe. Elle est aussi membre de l’équipe et participe activement aux travaux pendant un sprint[2].

La présence physique du PO avec l’équipe a un impact sur son rôle :

  • La situation idéale est un PO installé avec l’équipe, dans le même espace de travail. Cependant, il suffit qu’il soit assez proche pour que l’équipe puisse aller le voir et lui demander des précisions, et dans l’autre sens, pour qu’il puisse rencontrer facilement l’équipe.
  • Si le PO est à distance et ne voit pas physiquement l’équipe, la mise en œuvre du rôle sera plus délicate, mais il existe des solutions pour pallier son manque de présence physique.

En collaborant avec l’équipe, Céline apprend à écouter ce qu’ont à dire les développeurs. Elle comprend mieux leurs préoccupations de délai et de qualité[3]. Ainsi, elle sera moins encline à leur imposer une pression négative en les poussant à livrer toujours plus de fonctionnalités[4].

S’impliquer dans l’acceptation du fini

Comme il est moteur pour établir ce que doit faire le produit, il est logique que le PO fournisse aussi les conditions qui permettront de s’assurer que ce qu’il demande est bien terminé.

Lors des séances d’affinage[5], Céline a formulé à l’équipe le comportement qu’elle attend d’une fonctionnalité. Ensemble, ils ont identifié une condition d’acceptation. C’est en vérifiant que cette condition est satisfaite qu’elle s’assure de sa bonne fin.

Utiliser le produit

Céline aime son produit. Elle l’utilise tous les jours, ce qui l’incite à en faire un bon produit. Cela lui permet de discerner la valeur ajoutée par les fonctions dans le backlog.

Bien connaître son produit lui donnera une position respectée par tous et facilitera ses prises de décision.

C’est aussi dans sa mission de faire des démonstrations à l’extérieur et de présenter le produit aux utilisateurs. Elle en profite pour valider les hypothèses sur les nouveautés qu’elle envisage d’inclure dans le produit.

Impliquer les parties prenantes

Céline est imputable du résultat auprès des parties prenantes : pour bien exercer son rôle, elle doit communiquer avec elles.

Cela concerne non seulement les utilisateurs du produit final, mais aussi les clients comme les vétérinaires, et Gilles et Mona, bien sûr. Elle les invite à la revue[6] de chaque fin de sprint. Elle doit les inciter fermement, car la revue est un moment d’inspection collectif de l’état du produit.

Notes

[1] dans le livre, je n'écris pas productoneur. J'aurais peut-être dû. J'avais vraiment essayé productoneur et cela est repris dans un livre qui va sortir !

[2] et elle vient à la mêlée quotidienne, ce qui est recommandé pour le PO chaque fois que c'est possible, voir le chapitre 10. Elle participe également à la rétrospective, chapitre 12

[3] et elle en tient compte pour la planification du sprint, chapitre 8 et pour la planification de release, chapitre 16

[4] ce qui a tendance à provoquer de la dette technique

[5] l'affinage du backlog fait l'objet du chapitre 7

[6] la revue de sprint fait l'objet du chapitre 11