Q&R au sujet de l’ouvrage The Professional Product Owner

Les lecteurs d’InfoQ peuvent télécharger un extrait du livre The Professional Product Owner.

InfoQ s’est entretenu avec Don McGreal et Ralph Jocham sur les différentes couches de planification dans la gestion de produit agile, la livraison de produit, la façon dont Nexus soutient l’alignement entre les équipes, ce que signifie le fait d’être un Product Owner Professionnel, ainsi que le développement des compétences du Product Owner.

InfoQ : Qu’est-ce qui vous a décidé à écrire ce livre ?

Don McGreal : Ralph et moi-même avons tous deux été intendants du cours Professional Scrum Product Owner sur le site Scrum.org. Au fil des ans, nous avons travaillé avec Ken Schwaber et le reste de la communauté de formateurs de Scrum.org pour le redéfinir et le moderniser. Ralph et moi avons enseigné ce cours des centaines de fois, aussi avons nous pensé que ce serait une bonne idée d’écrire un livre, le compagnon idéal du cours.

Le thème que nous avons constamment vu parmi nos étudiants et dans l’ensemble de l’industrie, est que le rôle du Product Owner n’est pas bien compris. Il finit bien souvent soit comme secrétaire des besoins (scribe), soit comme passe-plat des besoins (proxy ou intermédiaire). Ce livre a pour but de réduire cette fracture en apportant au rôle les notions de responsabilisation et d’entrepreunariat.

InfoQ : À qui s’adresse-t-il ?

Ralph Jocham : À toute personne qui débute en tant que Product Owner. Ce livre est construit sur la formation PSPO (Professional Scrum Product Owner) de Scrum.org et la développe avec des idées, des concepts et des pratiques additionnelles qui ne peuvent pas être traitées sur un cours de deux jours.

McGreal : Comme le dit Ralph, ce livre est idéal pour les nouveaux Product Owners, mais il renferme aussi de nombreuses idées et techniques pratiques que des Product Owners avec plus d’expérience peuvent ne pas avoir rencontrées.

InfoQ : Quelles sont les différentes couches de planification de la gestion et de la livraison de produit agile ? Comment sont-elles construites les unes par rapport aux autres ?

McGreal/Jocham : Ceci est directement tiré de notre livre :

Au cœur de toute approche basée sur Scrum, il y a un plan quotidien dans un plan de sprint. Ces deux plans appartiennent à l’équipe de développement qui effectue le travail. Elle a toute autonomie dans le développement d’un plan qui réponde aux objectifs du sprint, ainsi que dans l’inspection et l’adaptation de ce plan de façon quotidienne.

Les deux couches externes de planification représentent la vision et la stratégie métier de l’organisation dans son ensemble. Elles appartiennent toutes les deux au comité exécutif ou au CEO, qui établit et communique la vision à l’échelle de l’organisation, et promeut une stratégie globale à l’aune de cette vision.

Il reste un espace vacant entre les objectifs de l’organisation au sens large et le travail fourni par les équipes de développement au jour le jour. Nous l’appelons le Vide de la gestion de produit. Il s’agit d’une motivation majeure pour l’écriture de ce livre. Ce vide a un besoin inné d’être comblé. Si vous n’y prenez pas garde, le vide de la gestion de produit sera rempli par du travail dénué de sens et une gestion approfondie de tâches. Toutes les couches du budget, des tableaux de projets, des transferts et de la répartition des tâches masquent l’intention de l’entreprise. Vous courez le risque d’être occupés sans avoir de direction claire.

Nous suggérons plutôt de remplir ce vide avec les trois V : Vision, Valeur, Validation.

• La Vision crée de la Transparence.
• Définir la Valeur vous donne quelque-chose à Inspecter.
• La Validation provoque l’Adaptation.

Notre livre dédie un chapitre à chacun des trois V.

InfoQ : Comment pouvons-nous savoir si nous avons un produit viable ?

Jocham : Le bonheur du client constitue la validation finale. C’est pourquoi nous devons nous rapprocher le plus possible de nos utilisateurs finaux en publiant fréquemment. La boucle de rétroaction des trois V (Vision, Valeur, Validation) a besoin d’être refermée aussi souvent que possible pour nous permettre de valider la valeur en observant les métriques prédéfinies. Nous parlons aussi de GBP (Gestion Basée sur la Preuve), une façon de mesurer la valeur au cours du temps.

McGreal : Il est primordial de formuler une hypothèse au plus tôt sur la valeur que l’on veut générer pour trouver une façon de la mesurer. La seule façon de faire bouger l’aiguille qui montre cette valeur est de publier. Les Product Owners qui trouvent des manières de publier plus tôt sauront plus tôt si leur produit est viable. Parfois, une publication précoce peut prendre la forme d’une simple preuve de concept, d’un sondage ou de toute autre expérience pour tester s’il y a seulement un marché.

InfoQ : Qu’est-ce qui retient les équipes de publier ? Comment peuvent-elles faire ?

McGreal : De par mon expérience, il y a trois raisons :

1.  Personne n’y pense. Il ont reccueilli des exigences et adopté un état d’esprit en mode projet : « C’est terminé quand les exigences sont couvertes. » Un bon Product Owner est la clé. Il doit constamment chercher le prochain MVP.
2. L’équipe de développement est bloquée. Son infrastructure et sa dette technique sont telles qu’elle ne peut pas arriver au « done » au cours du sprint. Cela prend une éternité de procéder aux tests de régression, au déploiement et à la fusion du code. La seule façon de s’en sortir est de commencer à payer la dette à chaque sprint jusqu’à ce que ces activités puissent être amenées dans un sprint.
3. On ne se concentre pas sur le « done ». Les équipes de développement terminent plus ou moins vaguement les éléments du carnet de produit car il n’y a pas d’accord clair et partagé sur ce que le « done » signifie, ce qui laisse une pile de travail à faire à la fin.

Jocham : Tout tourne autour du « done », qui veut dire qu’il ne reste plus rien à faire pour pouvoir publier. Scrum a plus de 22 ans, on le retrouve partout. Pourtant, la plupart n’arrivent pas à atteindre ce « done », mais ils continuent à travailler pour marquer une progression. La progression peut vouloir dire beaucoup. Elle peut aussi ne rien vouloir dire, ce qui les force à planifier la publication de versions majeures, certainement pas agiles et porteuses d’un risque élevé.

Pour de nombreuses organisations, la rustine consiste à avoir différentes définitions du « done » pour les différentes étapes avant une publication. Au départ, cela semble être une bonne idée, mais au final vous n’avez réussi qu’à masquer votre incapacité à atteindre le « done », et vous avez ainsi perdu la transparence.

La question d’atteindre le « done » est une question de timing. Quand atteignez-vous le « done » ? Une fois tous les deux mois à chaque version majeure ? Une fois par sprint ? Après la complétion d’un seul élément du carnet de produit ? Plus fréquemment ? Arriver à ce point signifie améliorer votre jeu en mettant à jour votre technologie, en minimisant les dépendances, en automatisant tout (les tests, l’intégration, le déploiement…).

InfoQ s’est entretenu avec Ken Schwaber au sujet du guide Nexus, un compagnon au Scrum Guide qui facilite l’utilisation de trois à neuf équipes Scrum dans un effort intégré de développement logiciel. InfoQ s’est aussi entretenu avec Patricia Kong en mars 2018 sur les mises à jour du guide Nexus.

InfoQ : Comment Nexus soutient-il l’alignement entre des équipes multiples ?

Jocham / McGreal : Passez votre produit à l’échelle, pas votre Scrum. Au lieu de découper votre produit en de nombreux petits composants, considérez-le comme un seul gros produit avec un seul carnet de produit et un seul Product Owner. Nous avons vu cela passer à l’échelle avec jusqu’à neuf équipes de développement. Avec neuf équipes de développement, vous avez assez de main-d’œuvre pour des produits de bonne taille.

Neuf équipes de développement qui tirent leur travail d’un seul produit menant à un seul incrément terminé requièrent une collaboration inter-équipes bien coordonnée. Cette collaboration inter-équipes est réussie quand vous avez un produit fonctionnel intégré chaque jour. Avant les mêlées quotidiennes régulières, il y a une mêlée quotidienne Nexus où des représentants de chaque équipe de développement vérifient que l’incrément est bien terminé. Si c’est le cas, tout va bien, sinon ils étudient la cause et listent des actions possibles à mener, puis rapportent cette information à leurs équipes de développement respectives qui l’intègreront à leur mêlée quotidienne. En termes de priorité, corriger le produit endommagé précède toujours les autres tâches, assurant ainsi un produit fonctionnel.

L’équipe qui se réunit pour la mêlée quotidienne Nexus est appelée l’équipe d’intégration Nexus.

Cela affecte aussi les autres événements comme la planification de sprint et la rétrospective de sprint, ainsi que la façon dont le raffinage est coordonné.

InfoQ : Que signifie être un Product Owner Professionnel ?

McGreal : En résumé, un Product Owner Professionnel a besoin de comprendre la perspective globale et de réaliser à qui s’adresse le produit. Quelles vies seront améliorées par ce que nous construisons, et qui a le plus à perdre si nous ne faisons pas les choses de la bonne façon.

Bien sûr, nous pouvons arriver à cela dans les temps et le budget impartis, mais qui en pâtira si ce n’est pas le bon produit ? Nous pouvons aussi livrer sans tenir compte de la maintenabilité ni du coût total de propriété, mais qui paiera pour cela au bout du compte ?

Jocham : Pour être un Product Owner Professionnel, vous devez initier et piloter le produit. Trop de Product Owners se trouvent du côté de la réception des exigences, on leur dit quoi fabriquer. Ils ne possèdent pas le produit ; ce sont plutôt des chefs de projet traditionnels.

Un Product Owner Professionnel comprend le métier pour lequel le produit est développé, et gère aussi le budget du produit, étant en capacité de prendre les décisions de compromis lorsque nécessaire. Encore mieux, un Product Owner Professionnel a un état d’esprit d’entrepreneur et traite chaque sprint comme s’il dépensait son propre argent.

InfoQ : Quelles sont les compétences dont ont besoin les Product Owners ? Comment peuvent-ils les développer ?

Jocham : Dans nos formations, nous avons un exercice où nous demandons aux étudiants de décrire les compétences d’un grand Product Owner. Au cours de centaines de formations avec des milliers d’étudiants, nous avons collecté quelques données intéressantes. En premier lieu, le Product Owner a besoin d’une forte connaissance du domaine et du métier, suivie de près par de fortes compétences en communication. Les autres compétences principales sont la négociation, les capacités analytiques, l’engagement et la gestion des parties prenantes.

Globalement, le Product Owner a besoin de ressentir la propriété du produit et d’en être fier, ainsi que la valeur qu’il fournit aux parties prenantes.

À propos des Auteurs

Ralph Jocham a passé les 20 dernières années à amasser de l’expérience en tant que professionnel dans le logiciel et dans le développement de produit en Allemagne, en France, au Royaume-Uni, aux États-Unis et maintenant en Suisse. Devenu évangéliste agile en 2000, il est formateur professionnel Scrum de Scrum.org et a enseigné à des milliers de professionnels autour du monde. Quand il n’est pas occupé dans sa société, Effective Agile, ou en train d’aider toutes sortes d’organisations en Europe, il aime enseigner à l’université. Jocham est intendant pour le cours Professional Scrum Product Owner de Scrum.org autour du monde.

Don McGreal, dans son rôle de vice-président des solutions d’apprentissage à Improving, est consultant pratique agile et instructeur. Il est spécialisé dans le coaching agile en entreprise et en gestion de produit au sein d’organisations de grande taille. McGreal est Professional Scrum Trainer de Scrum.org et a créé des cours et enseigné à des milliers de professionnels du logiciel autour du monde. Il est aussi co-fondateur de TastyCupcakes.org, une collection exhaustive de jeux et d’exercices pour accélérer l’adoption des principes agiles. McGreal est intendant pour le cours Professional Scrum Product Owner de Scrum.org autour du monde.