Synthèse chapitre sur le product owner dans SCRUM de Claude Aubry

Intro

• C’est pour éviter Le manque d’unité dans le contenu d’un produit que le Product Owner existe dans Scrum. Sa raison d’être est de faire en sorte que le travail fait apporte de la valeur. Il est responsable du succès du produit en définissant les priorités pour son développement.

• Le Product Owner permet d’éviter la prédominance de la technique dans un développement de produit. Il est le seul à avoir la responsablilité de guider l’équipe vers Le bon produit à réaliser, et ce afin d’éviter les conflits d’intérêt.
• Le Product Owner donne bien la direction, mais il n’a pas de responsabilité hiérarchique sur des personnes.
• définition du rôle de PO:

“Le Product Owner est la personne de l’équipe, et la seule, qui soit imputable du résultat auprès des parties prenantes.”

• Il convient de considérer le mot produit dans une acceptation large, comme le résultat de ce qui est fait par l’équipe. le Product Owner est responsable du résultat.

Activités du Product Owner

• Il agit à la fois sur la stratégie et la tactique.

• Les choix stratégiques => chef de projet ou du commité de pilotage. ex: date de livraison du produit et de son contenu.

• Les choix Tactiques => équipe de développement. ex: Priorisation du backlog?

• Le PO doit fréquemment prendre des décisions tactiques, d’où l’importance de sa présence dans l’équipe.

• Même si le Product Owner a des responsabilités, il ne faut pas le considérer comme quelqu’un qui impose ses choix de façon autoritaire ; beaucoup de travaux qu’il mène se font en équipe et ses décisions sont prises, chaque fois que c’est important, en accord avec elle.

Faire partager la vision

• La vision consiste à définir:

  • pourquoi on fait le produit,
  • le but de la prochaine release,
  • les impacts attendus sur les acteurs,
  • une liste des fonctionnalités essentielles qui y contribuent.*
  Le PO s’assure que l’ensemble des parties prenantes partagent la même vision.

Définir le Contenu du produit

• Le PO identifie les fonctionnalités requises, collectées auprès des parties prenantes, et les insert dans le backlog.

• le Product Owner s’occupe du backlog et passe une bonne partie de son temps à l’affiner, en anticipation sur les sprints suivants.

• Le PO est impliqué dans les tests d’acceptation car il doit fournir les conditions qui permettent de s’assurer que ce qu’il demande est bien réalisé.

Planifier la vie du priduit

• C’est le Product Owner qui définit l’ordre dans lequel les parties du produit seront développées. Il alimente l’équipe avec les fonctionnalités à développer,selon ses priorités.

• C’est aussi lui qui définit les jalons du cycle de vie du produit (les releases). Il définit l’objectif d’une release, comme son contenu ou sa date de mise à disposition auprès des utilisateurs.

Si le PO n’a pas d’autorité formelle sur les personnes, il influence grandement le produit réalisé.

Compétences souhaités

Avoir des compétences variées est une bonne chose.

Bonne connaissance du métier

• Le PO tire avantage des ses connaissances en relation avec l’utilisation du produit, ainsi que ses utilisateurs. Puisque Le PO représente, devant l’équipe de développement, l’ensemble de ces utilisateurs.

• Dans une configuration de développement de produit à usage interne, le PO peut parfois venir du groupe des utilisateurs.

• Dans une configuration de développelement de produit pour un client externe, le PO vient souvent des équipes Marketing ou produit.

• Lorsque le domaine fonctionnel est large, le PO pourra s’appuyer sur les bonnes personnes et lorsque celles-ci sont nombreuses, en désigner une, comme étant l’interlocuteur priviliégié. Ce sera le business owner.

Maitrise des techniques de définition de produit

• Pour définir ce que fait le produit, le PO collecte les besoins et les transforme en élément de backlog. => requirements engineering

• L’indentification des éléments de backlog se fait par les user stories

• “Il est souhaitable que le Product Owner ait la connaissance et si possible la pratique de techniques de définition de produit.”

Autorité (leadership) pour pendre des décisions rapidement

• Le PO doit pouvoir prendre des décisions seul, sans en référer à une hiérarchie. il doit avoir la confiance de l’ensemble des parties prenantes

• En cas de contratiction parmis les intervenants, le PO doit fédérer les points de vues en une seule proposition.

Capacité à détailler au bon moment

• Le PO décompose au bon moment les éléments prioritaire de backlog.

• Faire preuve d’anticipation

Esprit ouvert au changement

• Ajuster le plan et mettre à jour le backlog en fonction des feedback récoltés au fil des releases est au cœur de l’approche agile du PO.

• La Vision du PO ne varie pas fondamentalement pendant une release. => Ne pas être une girouette non plus..

Aptitude à la négiciation

• “Le Product Owner négocie fréquemment avec l’équipe et possède la force de conviction pour justifier ses prises de position.”

• L’établissement des priorités dans le backlog se fait en fonction de critères définis avec l’équipe. La valeur et le risque technique en font partie.

• Le PO vient au scrum quotidien pendant les sprint et reste si possible discuter avec les dévelopeurs afin d’entendre leurs propositions.

• Il lui arrivera de constituer un binôme avec un développeur, pour que celui-ci lui montre, sur son environnement de développement, le fonctionnement de la story sur laquelle il travaille.

Choisir le Product Owner d’une équipe

Une personne disponible

• “On estime que le travail, pour une équipe à partir de cinq personnes, nécessite une participation d’au moins trois heures par jour à disposition de l’équipe.”

• L’implication du PO est continue sur tout les sprint.

• Plus la fin de la release approche, plus le temps que le PO consacre au projet augmente. Les priorités sont plus difficiles à déterminer et le nombre de test augmente.

• Implication du PO du un sprint de deux semaines:

  • réunion de planification de sprint : environ deux heures,
  • scrums quotidiens, deux fois par semaine (c’est un minimum): 60 minutes pour quatre séances,
  • meeting d’affinage : environ deux heures
  • revue de sprint : 60 minutes,
  • rétrospective : 60 minutes.
  Cela fait sept heures, soit environ 10 % de son temps

• En plus de participer à ces réunions, le Product Owner se doit aussi de :

  • d’affiner seul le backlog, ajuster les priorités,
  • répondre aux questions sur le produit,
  • définir les conditions d’acceptation,
  • passer les tests ou s’assurer qu’ils sont bien passés.

Une seule personne

• Le PO est le seul décideur face à l’équipe, de ce que doit faire le produit.

• Il faut parler d’une seule voix à une équipe et cette voix, c’est celle du Product Owner.

• Il y a eu des exemples dans lesquels le PO n’était pas suffisamment disponible et avait désigné un délégué. Cela pose problème, car le risque d’avoir “deux sons de cloche” augmente lorsque le PO s’exprime à la suite de son délégué. => mieux vaut alors désigner le PO comme étant partie prenante, et son délégué comme le véritable PO, au moins jusqu’à la fin de la release en cours.

• Ce qui définit le rôle de PO c’est de d’établir les priorités.

• Le PO est une seule personne, pas un commité

Où le trouver dans l’organisation actuelle

• Le PO sera plutôt désigné au sein d’un “service” différent de l’équipe de développement. ex: Chez un éditeur de logiciel, le PO fera souvent partie du service marketing ou du service produit. Il aura plus de chance de cristaliser les compétences requises.

• Dans les entreprises qui ont des utilisateurs internes, on priviligiera ce groupe de personnes pour y piocher un PO. => Attention au manque de disponibilité.

• Dans celles qui ont généralement un chef de projet pour tous leurs produits, on choisira cette personne là pour sa qualité de leader. Mais pas de chef !

Une personne motivée pour le rôle

• “Le Product Owner fraîchement nommé a parfois une culture de Scrum et de l’agilité superficielle. Il pourra recevoir des compléments de formation plus tard mais ce qui importe lors du choix, c’est son adhésion aux valeurs et principes véhiculés par le mouvement agile.”

Conseils pour progresser dans le rôle

• “Les équipes Scrum qui sont en échec le sont souvent à cause du manque de savoir-faire du Product Owner.”

Se former au rôle de Product Owner

• être accompagné dans sa mise en oeuvre par un coach sous forme de binôme peut être une bonne chose.

S’impliquer dans les test d’acceptation

• “C’est la responsabilité du Product Owner de s’assurer que le travail réalisé par l’équipe est fini pendant le sprint.”

• “C’est en exposant ses conditions d’acceptation que le Product Owner formule à l’équipe le comportement qu’il attend d’une fonctionnalité.”

• Ces conditions peuvent être:

  • formalisées de manière informelle => communication améliorée,

  • formalisées en Test d’Acceptation => Automatisés et passés régulièrement. Cette dernière approche s’appelle spécification par l’exemple

Collaborer avec l’équipe

• Le PO n’est pas uniquement représentant des utilisateurs auprès de l’équipe, il fait partie de l’équipe. Il paticipe au travaux pendant le sprint.

• Dans l’idéal, le PO s’installe dans le même espace de travail que l’équipe de développement.

• Dans les cas où sa présence physique n’est pas possible, les outils de travail collaboratifs sont de bonnes alternatives.

Utiliser le produit

• “Un bon Product Owner aime son produit. S’il l’utilise tous les jours, il y a des chances qu’il soit incité à en faire un bon produit. Il sera plus à même de discerner la valeur ajoutée des fonctionnalités présentes 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. Il en profitera pour valider les hypothèses sur les nouveautés qu’il envisage d’inclure dans le produit.”

Impliquer les parties prenantes

• Le PO invite les parties prenantes à la revue de chaque fin de sprint (Utilisateurs, sponsors etc.). Il doit les inciter à y venir car cette revue est un moment d’inspection collectif de l’état du produit.

Planifier à moyen terme

• “Une des pratiques de Scrum les plus mal utilisées, d’après mon expérience, est la production d’un plan de release. C’est pourtant un moyen de donner une direction à l’équipe et de la communiquer aux parties prenantes. Le Product Owner est moteur dans cette quête d’avoir un horizon qui va au-delà du sprint courant.”

S’intéresser aux nouveaux outils

• “Impact mapping, story mapping, innovation games, ces outils permettent au PO de dépasser Scrum.”

Par quoi démarrer

Se mettre d’accord sur les droits et devoirs du PO

• “Une fois le PO choisi, il collabore avec le reste de l’équipe pour définir la façon dont ils vont travailler ensemble.”

Une bonne lecture

• “Le livre Exploring Scrum explique très bien le rôle de PO”

En résumé

• “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.”