Plusieurs PO pour une équipe de dév, comment prioriser ?

read time

4 min

Plusieurs PO pour une équipe de dév, comment prioriser ?

Cet article est un extrait de notre livre sur l’Agile Product Management. A travers ce livre, découvrez nos méthodes, nos outils et nos convictions pour vous aider à créer les bons produits !

« Un backlog, une équipe, un Product Owner ! ». Voilà la bonne façon de s’organiser. Product Owner, c’est un métier à temps plein, entre la gestion du backlog, l’alimentation de l’équipe, répondre à des sollicitations…
Dans certains cas, il arrive qu’un Product Owner soit obligé de partager avec d’autres Product Owners une même équipe de développement. Cela peut venir de la culture de l’entreprise ou de contraintes organisationnelles. Un tel mode de fonctionnement est un anti-pattern agile. Vous êtes dans cette situation ? Nous allons vous expliquer comment faire au mieux.

Cas numéro 1 : Une équipe, plusieurs projets, plusieurs Product Owners

Vous vous retrouvez au sein d’une équipe alimentée par plusieurs Product Owners, pour traiter plusieurs projets en parallèle ; il s’agit, de facto, d’un centre de services. Dans ce type d’organisation, l’équipe de développement risque de devoir prioriser elle-même son backlog afin de tenir ses engagements auprès de toutes les parties prenantes.

Cas numéro 2 : Une équipe, un projet, plusieurs Product Owners

Cette situation est typique d’une équipe dont la taille trop importante la rend difficile à alimenter par un seul Product Owner. Cela peut également arriver dans le cas où des expertises métier très pointues sont nécessaires. Il faut alors identifier un Product Owner par domaine de compétences. Les risques inhérents à ce mode organisationnel sont : la difficulté à alimenter l’équipe de développement, la complexification de la priorisation et le moindre alignement.

Conséquences

L’équipe devient alors un goulet d’étranglement, et les conséquences sont connues : problèmes de qualité, usure des personnes, tensions, etc. Malheureusement, les leviers nécessaires au changement organisationnel sont rarement entre les mains des Product Owners ou de l’équipe de développe-ment, il faut donc faire avec. Comment gérer une telle situation ?

Une solution : mettre en place votre Kanban du Ready

Sans avoir à révolutionner votre mode de fonctionnement, une solution à mettre en oeuvre consiste à rationaliser et rendre visible la situation actuelle dans le but de provoquer une prise de conscience et d’aboutir à des améliorations. Vous êtes dans la situation d’un centre de services, prenez cet état de fait en compte. Votre équipe de développement a une capacité à faire, et celle-ci n’est pas extensible. Souvent, chaque Product Owner a sa propre roadmap, ses propres échéances et ses propres engagements. Cette situation peut vite devenir problématique. Comment l’équipe de développement obtient-elle une priorisation indiscutable des éléments de travail ? Par quoi commencer ? Dans le cas d’un centre de services, il faut voir l’équipe comme un système et penser en flux. Bref, adopter une logique Kanban. Que vous vous trouviez dans l’un ou l’autre des deux cas décrits plus haut, la colonne du management visuel où l’équipe de développement s’alimente doit être unique, correctement priorisée grâce au travail de l’ensemble des Product Owners concernés. Cela signifie que l’ultime étape du travail des Product Owners est une phase d’alignement sur les priorités pour le développement. Ces priorités sont explicitées dans la colonne Ready to dev (Prêt à développer) du Kanban.

kanban du ready
Product Managers : créez un Kanban du Ready !

En plus de l’alignement sur les priorités de développement, ce Kanban du Ready a deux grandes vertus :

  • Les éléments de travail pour l’équipe de développement ont une forme cohérente.
  • L’équipe de développement dispose d’une vision exhaustive de l’activité des Product Owners et un aperçu de ce qui les attend très prochainement.

Dans le schéma ci-dessus, chaque Product Owner voit son activité affichée dans une ligne de nage du Kanban global. Une fois qu’un nombre suffisant de user stories sont matures pour lui et ses condisciples, il est possible de déclencher une séance de présentation des user stories à l’équipe, de collaborer entre Product Owners et de déterminer le bon ordre de priorité, non ambigu, des user stories à envoyer en développement. Les Product Owners doivent s’entendre là-dessus !

C’est également le moyen d’adopter une approche de juste à temps pour la
maturation des user stories : l’équipe de développement a une capacité fixe, un
débit. Il faut prendre en compte ce débit jusque dans l’expression des besoins,
la planification des ateliers métier, la sollicitation éventuelle des équipes de test,
etc. L’utilisation de limites sur les activités de votre système va permettre le
passage d’un flux poussé vers un flux tiré. Le travail d’alimentation des Product
Owners va donc se caler sur la capacité d’absorption des développeurs. En
effet, pourquoi écrire, discuter, estimer, bref, perdre du temps sur des user
stories que l’équipe n’a pas la capacité d’absorber ? Les Product Owners au
« chômage technique » seront alors plus utiles à aider l’équipe à tester ce qui
est commencé ou d’autres Product Owners à finir de rédiger les user stories
les plus importantes. On appelle cela le “swarming”.

Selon votre contexte et la culture de la société dans laquelle vous évoluez, une
équipe de Product Owners peut utiliser cette approche pour s’aligner sur les
priorités et obtenir cette fameuse colonne unique et priorisée “Ready to dev” -
« Prêt à être développé ». Parfois, le consensus est facilement atteint.

Malheureusement, nous avons parfois besoin de prioriser et donc de quantifier l’intérêt de telle user story par rapport à telle autre. Dans ce cas, manipuler la valeur métier ne suffit pas – cette valeur est de toute façon souvent incomprise ou mal utilisée. Une bonne approche est alors d’utiliser une forme minimale de coût du délai. Combien me rapporterait ou me ferait économiser une user story si elle était livrée ?

Quatre classes de services sont généralement utilisées pour classer les éléments de travail : 

  • Urgence : une user story qui rapporte ou fait économiser immédiatement de l’argent à l’entreprise ; chaque jour qui s’écoule constitue donc un manque à gagner.
  • Date fixe : une user story qui doit être livrée à une date donnée, typiquement une obligation légale. Au delà de cette date, chaque jour écoulé risque de faire perdre une somme importante (une amende par exemple).
  • Standard : une user story classique qui a une valeur business, chaque jour écoulé vous éloigne d’un gain potentiel.
  • Intangible : typiquement la dette technique, l’intangible ne presque coûte rien jusqu’au moment où il est trop tard, la bonne pratique est de gérer un peu d’intangible tout le temps.

Cette technique de priorisation est un moyen simple pour challenger la valeur d’éléments de travail, notamment pour des lignes produit ou projet de prime abord « incomparables ». Dans tous les cas, l’esprit agile doit prévaloir : la résolution des questions liées à ce mode de fonctionnement est grandement facilitée par un esprit d’équipe à toute épreuve et le partage de la vision. La mise en place d’un Kanban du Ready rendra le problème visible mais ne remplacera jamais l’échange entre les Product Owners. Une cérémonie stricte de priorisation calée sur un rythme régulier est indispensable. La mise en place d’une communauté de pratique des Product Owners facilitera l’alignement, la transparence et renforcera l’esprit d’équipe.

Pour aller plus loin : Téléchargez notre livre sur l'Agile Product Management

Publié le 16 avr. 2015

Mis à jour le 01 juil. 2022

clipboardCopier le lien
Ecrit par
Alexandre Irrmann-Tézé
Alexandre Irrmann-Tézé Alexandre est cofondateur et directeur général de Thiga. Diplômé de Télécom ParisTech, il a débuté sa carrière dans un grand cabinet de conseil en management, puis il décide de voler de ses propres ailes avec son acolyte Hugo Geissmann.

Les prochains évènements

Comment te lancer en Product Management ? 🚀

calendar

5 avr 2022

Découvrir

Le recrutement : réponse à toutes tes questions indiscrètes 👀

calendar

6 avr 2022

Découvrir

Ma place dans l'équipe en tant que Product Designer 📍

calendar

7 avr 2022

Découvrir

La Product Conf Paris

calendar

9 juin 2022

Découvrir

Filles_ordinateur

Envie de partager tes idées ?


Plus de 20.000 passioné.e.s du Produit viennent sur notre média chaque mois. Retours d’expérience, opinions clivantes, n’hésite pas à nous proposer des contenus.

 

Contacter la rédaction