Plusieurs product owner dans une équipe ?

plusieurs product owner
plusieurs product owner

Est-il possible d’avoir plusieurs product owner dans une équipe Scrum ? Et si vous êtes dans ce cas, comment optimiser cette pratiques ? Nous allons voir cela dans cet article.

Vous pouvez regarder la vidéo de La Minute Agile sur le sujet réalisée avec l’excellente Amina Bourguiba :

Plusieurs product owner dans une équipe Scrum ?

Le Scrum Guide dit NON !

Alors si nous nous arrêtons sur le Scrum Guide, il est assez formel sur le sujet :

Une équipe Scrum comprend un Product Owner, une équipe de développement (Development Team) et un Scrum Master.

scrum guide fr

Et si on est agile ?

Donc si nous faisons du scrum by the book, cette pratique est donc clairement interdit par le Scrum. Cependant, en agile, nous disons régulièrement qu’il faut s’adapter au contexte et être capable d’avoir une certaine flexibilité.

Contexte fréquent avec plusieurs product owner

En effet dans certaines structures, l’agilité n’est pas encore un pilier de sa culture. Et il n’est pas rare de voir des « dits » product owner qui ne sont pas liés à un produit mais à une expertise particulière sur de gros produits.

Et ce type d’organisation complexifie considérablement le travail des équipes qui tentent tant bien que mal à mettre du Scrum en place. Doit-on dire à ces équipes d’abandonner Scrum ou les aider à faire face à ce contexte ? Après tout, tout un travail de réorganisation peut se faire en parallèle pour améliorer ce contexte complexe.

Partant dans l’idée d’aider les équipes, nous allons voir quelques astuces non négligeable pour améliorer ce type de contexte.

Plusieurs product owner pour une équipe – nos astuces

Un product owner en interlocuteur principal

La première astuce proposée serait de voir si il n’est pas possible d’avoir un seul PO comme interlocuteur principal de l’équipe. Si celui-ci n’écrirait pas toutes les user-stories (pas au démarrage), il serait le responsable d’un backlog unique !

Et avec un peu de coaching, il serait même possible peu à peu d’amener cet interlocuteur principal à écrire en partie l’ensemble des user-stories. Ceci placerait les autres product owner en tant que parties prenantes… Et au final, on irait peu à peu vers une véritable organisation Scrum.

Pour cela, rassemblez l’ensemble des product owner et voyez avec eux, celui qui semble avoir le plus d’impact avec cette équipe et qui serait prêt à prendre ce rôle de centralisateur. Et si il n’y a pas de consensus sur le sujet, il sera toujours possible de voir avec le sponsor du projet, si il peut aider dans cette désignation.

Avoir un backlog unique

Il est essentiel d’avoir qu’un seul backlog autour du produit géré par cette équipe scrum. Il n’est pas rare que chaque product owner ait son backlog mais cela complexifie considérablement la priorisation et la standardisation des items (user-stories).

L’utilisation d’un board de maturation des user-stories pour l’ensemble des PO pourra également fortement aider à la standardisation de l’écriture des user stories. 

Priorisation entre les product owner

Afin de constituer les prochaines itérations (tout en respectant la capacité de faire de l’équipe de développement), il est recommandé que les product owner se rassemblent régulièrement pour prioriser ensemble l’ensemble de leurs éléments respectifs.

Pour cela, ils doivent tenter de définir une valeur commune pour que chacun des éléments ait une valeur claire, comparable et exploitable. Sans ce travail de priorisation en groupe, l’équipe de réalisation subira considérablement les priorisations chaotiques durant les sprint planning.

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 942 Articles
  Paquet Judicaël (expert en transformation et AI) Mes activités en France et en Suisse : - ingénieur prompt - coach AI - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile, prompt AI, Intelligence artificielle. [Me contacter]

1 Commentaire

  1. Merci pour cet article
    Je rencontre les mêmes difficultés
    En effet suite a une transformation vers du produit et passage de cp en PO on se retrouve avec plusieurs produits en stand alone mais aussi intégrés à un gros produits
    A mon sens on a trop de produit et po qui sont découpés par pôle gouvernance, quality …
    On a avait de 1/2 scrum voire dev et aucune cohérence pour créer des parcours utilisateurs qui font sens
    On s’adapte à l’organisation on a tout rationalisé
    On a effectivement un lead PO qui pilote le gros produit une équipe de dev et des proxy po par compétences et se synchronise
    Ça fonctionne et on priorise
    Certains ne sont pas en phase avec ce fonctionnement mais l’organisation et la maturité de l’entreprise ne nous permettent pas de faire autrement

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.