#8. Plusieurs Product Owners pour une équipe de développement : comment prioriser ?
Ou comment éviter les disputes lors du sprint planning…
« 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 #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 #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éveloppement, il faut donc faire avec. Comment gérer une telle situation ? Voici quelques clés pour s’en sortir.
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.
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.
Cet article a originalement été publié dans notre Product Academy. Si vous voulez un compagnon physique demandez votre exemplaire sur notre site !
Et si vous avez aimé cet article, n’hésitez pas à nous donner un petit coeur !
