Le Proxy Product Owner : une fausse bonne idée ? 🚫

Le concept de Proxy Product Owner fait débat. Beaucoup le voient comme une solution pratique, mais il peut générer plus de problèmes qu’il n’en résout. Si vous avez déjà entendu parler de ce rôle ou si vous l’avez dans vos équipes, prenons un instant pour réfléchir : est-ce vraiment une bonne idée ?

Le rôle du Product Owner, rappel des bases

En Scrum, le Product Owner (PO) a deux responsabilités clés :

1. Maximiser la valeur du produit.
2. Gérer efficacement le Product Backlog.

C’est un rôle unique et central dans une équipe Scrum. Quelques points à garder en tête :

Un PO, et un seul. Pourquoi ? Parce que cela garantit des décisions claires, rapides et alignées. Dès qu’on introduit un proxy PO, on divise cette responsabilité, et on entre dans une dynamique de comité.

Pourquoi le proxy PO pose problème

Imagine un instant :

• Deux personnes partagent la responsabilité du Product Backlog.
• Ces deux personnes doivent prendre des décisions sur le produit.

Maintenant, visualise la scène suivante :

Un manager arrive avec une demande urgente. Le proxy PO prend une décision rapide pour répondre à l’urgence. Mais quelques heures plus tard, le « vrai » PO apprend cette décision et… n’est pas d’accord.

Conséquences ?

En Scrum (et en Agile en général), on cherche à simplifier les processus, pas à les complexifier. Et un rôle comme le proxy PO va à l’encontre de cette philosophie.

Que faire si le PO est débordé ?

Le recours à un proxy PO est souvent un symptôme d’un problème plus profond : le Product Owner a trop de responsabilités ou manque de temps pour remplir son rôle correctement. Voici des pistes pour éviter la d’en arriver là :

1. Le PO délègue une partie du travail à l’équipe

Un PO peut déléguer certaines tâches, comme :

• Rédiger les items du Product Backlog
• Estimer ou prioriser certains éléments.

2. Le PO est-il le bon rôle ?

Parfois, le PO désigné est en réalité une partie prenante, et le proxy PO joue le rôle du véritable Product Owner. Si c’est le cas, posez-vous la question :

Si oui, clarifiez les rôles : il vaut mieux avoir un seul PO pleinement investi que deux personnes aux responsabilités floues.

Une organisation qui respecte le rôle du PO

Pour qu’un PO réussisse, il a besoin de soutien à deux niveaux :

1. L’organisation doit respecter ses décisions. Les parties prenantes doivent comprendre que le PO est le décideur final pour tout ce qui concerne le produit.
2. L’équipe doit l’aider à gérer la charge de travail. En collaborant sur le Product Backlog et en prenant en charge certaines tâches opérationnelles, l’équipe peut alléger la pression sur le PO.

Et si ça marche bien chez vous ?

Certaines équipes disent que le modèle du proxy PO fonctionne bien dans leur contexte. Mais posez-vous cette simple question :

Le rôle de Scrum est de simplifier, d’éliminer les goulots d’étranglement et de maximiser la valeur livrée. Si le proxy PO complexifie la prise de décision ou ralentit le processus, c’est un signal d’alarme.

Et vous, comment ça se passe dans votre équipe ?

Avez-vous déjà expérimenté le rôle de proxy PO ? A-t-il aidé ou compliqué les choses ? Partagez vos expériences ou vos solutions pour gérer un PO débordé !