Product Owner

Cela fait une vingtaine d’années que l’usage du mot backlog, provenant de Scrum, s’est répandu dans le domaine de l’agilité. Cette — déjà longue — histoire est passée par des moments différents : au début il s’agissait de le promouvoir comme outil de collecte en remplacement des gros documents de spécification, ensuite de montrer qu’il ne s’agissait pas simplement d’une liste mais qu’il y avait du travail de réflexion et d’amélioration — l’affinage — avant qu’un élément du backlog rentre dans un sprint. Maintenant l’enjeu porte sur l’usage du backlog en alignement avec la stratégie et un modèle de valeur.

C’est le 5 décembre 2006 que j’ai écrit le premier article de description du rôle de Product Owner. En 2022, j’ai publié l’édition 6 de mon livre Scrum en réécrivant le chapitre qui lui est dédié. L’occasion de voir ce qui a évolué dans le rôle et dans la façon de le présenter.

Dans l’édition 6 de Scrum publiée début 2022, j’ai divisé le livre en 5 parties. La première s’appelle L’écosystème ; elle contient les chapitres sur les rôles Scrum : équipe, Scrum Master, Product Owner et — nouveautés ! — coéquipier et partie prenante. Cette évolution me donne l’occasion de revenir sur les définitions des rôles Scrum, sans considération pour celles du Guide Scrum.

Suite de l’étude des relations du Product Owner dans son écosystème, perçues selon le paradigme du don étendu : Demander - Donner - Recevoir - Rendre Après les relations avec les parties prenantes et les utilisateurs, voici, avec l’exemple de Lucas (le Product Owner de PermaBio) celles avec le vivant et l’équipe.

Cet article est tiré de l’ebook L’agilité, extension du domaine du don publié par le collectif Agile Radical à l’occasion du calendrier de l’avent. L’extrait porte sur le point de vue du Product Owner dans ses relations avec les parties prenantes ; il a été sensiblement remanié à l’occasion. Cette réécriture constitue la 3e partie de cette série sur le don.

L’extrait porte sur le récit de Lucas, Product Owner de PermaBio. La première partie aborde la notion de valeur à travers l’histoire de Lucas, qui a évolué d’une vision utilitariste vers le paradigme du don.

Le Manifeste agile met en avant la collaboration avec le client plus que la négociation du contrat. Dans notre précédent article, nous avons constaté qu’en fait, sur le terrain, ce qui s’est passé dans les équipes agiles, c’est : la coopération avec le Product Owner plus que la collaboration avec le client C’est bien. Mais il est temps d’aller encore plus loin.

Cet article fait suite au commentaire d’Aurélie sur Twitter à propos du manifeste agile radical. Je vais tenter de contribuer à plus de clarté car elle nous dit : le lien entre le réchauffement climatique et la collaboration avec le client n’est pas clair pour moi

PermaBio est l’exemple qui sert de fil rouge dans L’art de devenir une équipe agile. Dans le premier chapitre, nous avions fait connaissance avec Pierre, le fondateur, qui nous avait donné sa vision, décrit le service et expliqué pourquoi l’agilité lui semblait la bonne approche. Nous allons maintenant faire connaissance avec l’équipe.

Doug Shimp et Dan Rawsthorne sont les auteurs du livre Exploring Scrum. À mon avis, ce livre est le meilleur qui existe sur Scrum en anglais, le plus fouillé et le plus innovant tout en restant dans l’essence de la méthode. C’est pourquoi je porte une grande attention à l’article Scrum3.0 qu’ils viennent de publier.

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.

Jeudi c’est le ScrumDay. J’y présenterai “Les nouveaux outils du Product Owner”.

Voici ce que j’avais proposé comme descriptif :

J’avais entendu parler du PODojo, atelier destiné aux Product Owners pour s’améliorer par la pratique. Le PODojo est au PO ce que les coding dojos sont aux développeurs. Il s’en était déroulé quelques uns lors des conférences agiles l’an dernier.

Plutôt que de proposer plein de dates dans un catalogue et d’en annuler les 3/4 comme le font la plupart des organismes de formation industrielle, j’ai décidé, en accord avec les camarades de la Fédération Agile qui animent avec moi, de n’officialiser la date d’une session qu’une fois sa viabilité assurée.

Pendant les vacances, j’ai commencé une série de billets visant à apporter des informations additionnelles aux lecteurs de mon livre Scrum. 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…

Avant de parler de mes formations Scrum, un coup de pouce à deux initiatives originales : une avec Don et l’autre avec Dan.

La meilleure formule pour avoir un feedback très rapide : mangez votre propre nourriture pour chien ! J’ai redécouvert cette métaphore qui date déjà de quelques années : Eating Your Own Dog Food.

J’écris l’édition 3 de mon livre Scrum. Quand mon éditeur m’avait suggéré cette nouvelle édition, j’avais demandé ici dans ce billet ce qu’il paraissait intéressant d’y ajouter. Dans son commentaire, FXMaq m’a orienté vers le mûrissement de backlog. Bonne idée. En fait j’en parle déjà dans l’édition deux. Dans le §5.4.2 donc à la fin du chapitre sur le Backlog je conseille dans les choses à essayer de “Cultiver son backlog”. C’est ce que FXMaq appelle joliment mûrir et qui vient de l’anglais grooming.