Christine Hegarty de Scrum Inc. a écrit ceci aujourd'hui, juste avant qu'elle ne parte en vacances, bien sûr, alors je le poste pour elle - jj
Chez Scrum Inc., nous avons beaucoup réfléchi au rôle de Product Owner ces derniers temps. Il s'agit d'une question à laquelle de nombreuses entreprises sont confrontées. Il est de notoriété publique dans le monde du Scrum qu'un bon Product Owner augmentera le chiffre d'affaires en maintenant le carnet de commandes afin de produire plus tôt les produits à forte valeur ajoutée. Mais la manière dont ils y parviennent n'est pas toujours claire. Nous avons donc décidé de proposer des cours de Product Owner pour aider à former les Product Owners sur la manière dont ils peuvent augmenter la valeur de l'entreprise et le chiffre d'affaires. J'ai travaillé avec Catherine Louis pour lancer notre première formation Product Owner dans la région de Boston ce mois-ci. Début mars, Jeff donnera le cours Product Owner qu'il a développé à Los Angeles.
Lors de l'élaboration de la classe, Catherine et moi avons passé beaucoup de temps à discuter de l'importance du rôle pour une bonne mise en œuvre du Scrum. Les passages suivants reflètent certaines de nos conversations sur le rôle du Product Owner et j'ai pensé qu'il serait intéressant pour la communauté d'en discuter.
Q : Qu'est-ce qui rend le rôle de Product Owner (PO) particulièrement difficile ?
R : Le PO est la personne qui peut répondre à cette question : "Est-ce la bonne chose à faire pour le client ?" Ce n'est pas une mince affaire ! Le PO est quelqu'un qui est confronté au marché : il est capable d'élaborer et de relayer une vision. Le PO est une personne très proche du client ; il est le propriétaire d'un Backlog de produit et se concentre sur l'apport de valeur (et d'enchantement !) au client. Il est également chargé de maintenir un carnet de commandes ordonné de sorte que les éléments situés en haut du carnet de commandes soient de taille appropriée pour que l'équipe puisse commencer à travailler dessus et qu'ils soient prêts à être pris en charge lors du premier sprint.
Ce rôle ne peut être assumé seul : le PO est considéré comme un membre de l'équipe et peut avoir besoin de l'aide de nombreuses parties prenantes pour ordonner le carnet de commandes, en veillant à prendre en considération le facteur de Pareto : c'est-à-dire que les 20% les plus importantes du carnet de commandes doivent contenir la valeur la plus élevée.Q : Quels sont les principaux pièges à éviter ?
R : En général, nous rencontrons de nouveaux PO qui sortent d'une culture de développement traditionnel par lots/phases, qui traitent avec des équipes plus importantes et spécialisées, avec un objectif de perfection initiale et de "signature des exigences".
Dans le cadre d'un développement traditionnel/en cascade, l'évolution des exigences est découragée, et il existe un plan parfait et un objectif associé pour livrer de la valeur à la fin d'une version. Nous ne pouvons pas ignorer le changement culturel massif nécessaire à la gestion d'un carnet de commandes émergent. Nous voulons voir un flux de valeur, une collaboration avec le client, des équipes intégrées et plus petites auto-organisées, avec une valeur générée de manière incrémentale.
Ce changement culturel nous fait passer de l'élaboration d'un plan à sécurité intégrée que nous voulons exécuter et livrer à la fin d'une version, à un cadre "sûr d'échouer" dans lequel nous apprenons et améliorons chaque itération. Ce changement culturel nous permet de transformer cette évolution attendue des besoins en avantage concurrentiel.
Q : Ce changement de culture concerne donc beaucoup plus de personnes que l'équipe Scrum, y compris l'équipe Product Owner...
R : Le PO est un élément clé de la transition vers Agile, mais comme il s'agit d'un changement d'état d'esprit pour l'ensemble de l'organisation, de nombreux acteurs doivent être impliqués dès le début, des rôles qui ne sont pas normalement considérés comme des rôles Scrum. Les rôles de soutien, en particulier, ne doivent pas être oubliés.
Prenons l'exemple des RH. Nous sommes désormais constitués en équipes auto-organisées, auto-motivées et autogérées, et la structure de récompense doit être mise à jour pour reconnaître et récompenser les performances de l'équipe. Imaginez ce qui pourrait arriver si cela ne changeait pas. Prenons l'exemple de la gestion de projet : Nous sommes maintenant formés dans ces mêmes équipes, mais il y a un chef de projet qui est responsable des résultats et qui demande des rapports quotidiens sur l'état d'avancement du projet lors de réunions hebdomadaires.
Lorsque l'on décide de passer d'un développement de produit traditionnel à un développement Lean/Agile/Scrum, je recommande d'examiner toutes les personnes impliquées, depuis la décision initiale jusqu'à la livraison de la valeur au client. N'oubliez pas le cadre des rôles de soutien qui doivent être présents en tant que Servant Leaders pour éliminer les obstacles, dégager le chemin et soutenir le flux de valeur (les produits livrables) vers le client. Tout le monde doit être sur la même longueur d'onde : Pour chaque décision que vous prenez, chaque jour, posez-vous la question suivante : "Est-ce la bonne chose à faire pour le client ?" Si la réponse est "non", ne le faites pas. Si la réponse est "oui", dites "oui" et faites-le tout de suite. Si la réponse est "je ne sais pas", confiez la décision au Product Owner.
Le cours Product Owner de Catherine à Boston se tiendra les 14 et 15 février à Boston. Le cours Product Owner de Jeff Sutherland, pour ceux d'entre vous qui se trouvent sur la côte ouest, aura lieu à Los Angeles les 1er et 2 mars.
French 
English 
Spanish