Point de départ. La vidéo de Henrik Kniberg présente le rôle en 15 minutes. Ce chapitre en reprend les idées, puis précise d'où vient l'intention du PO et ce qui se passe quand un développeur tient aussi ce rôle.
La vidéo de Henrik Kniberg donne une vue d'ensemble claire du rôle.
Agile Product Ownership in a Nutshell, Henrik Kniberg, 2012. Sous-titres français disponibles.
Le PO et sa vision, les parties prenantes, la capacité de l'équipe, la file d'attente qui grossit et le mot « non », la valeur qui ne dépend pas de la taille, l'affinage du backlog, les trois compromis, la prévision par les deux droites de tendance.
« The most important job of the product owner is to decide what NOT to build, and taking the consequences of that decision. » Henrik Kniberg
Premier complément. La vidéo commence par la vision, et n'explique pas comment elle se forme.
Kniberg présente Pat en disant qu'elle a une vision du produit qui la passionne. La vision est là dès la première image, elle vient d'elle.
Ma lecture est un peu différente. L'intention d'un PO se construit en écoutant quatre sources qui ne disent pas la même chose :
| Source | Ce qu'elle pousse | Ce qu'elle voit mal |
|---|---|---|
| Les développeurs | ce qui est faisable, ce qui tient dans le temps | ce dont l'usager a besoin |
| Le Product Manager | le marché, la position, le modèle économique | le coût réel de construction |
| Les parties prenantes | leur besoin à elles, en premier | l'ensemble des autres besoins |
| Les personnes usagères | ce qui les gêne aujourd'hui | ce qui les aiderait demain |
Ces quatre positions sont en tension légère et permanente. Aucune n'a tort. Le travail du PO est de les écouter assez longtemps pour que son intention se forme, puis de trancher.
Un PO qui arrive avec son idée déjà faite se prive de ces quatre sources. Il décide vite, et il décide seul.
Dans une petite équipe, le rôle de PO est parfois tenu par un développeur. Cette configuration mérite une attention particulière.
| Réflexe de développeur | Posture de PO | |
|---|---|---|
| Première question | comment on le construit ? | quel problème on règle ? |
| Ce qu'on cherche | la faisabilité, la qualité technique | la valeur, la priorité |
| Rapport à la solution | on en imagine une tout de suite | on retarde le moment d'en choisir une |
Les deux façons de penser sont bonnes, chacune à sa place. Un développeur qui pense en solutions fait bien son travail. Un PO doit rester sur le problème plus longtemps que ça ne lui est naturel. Et, ça créé une tension tranquille et bénéfique entre les deux rôles.
Le cumul réunit deux pouvoirs différents dans la même personne : décider ce qu'on fait, et participer à décider comment on le fait.
Il y a une tension saine entre les rôles Scrum. Le PO tire vers construire la bonne chose, l'équipe tire vers bien la construire. Quand une seule personne tient les deux bouts, cette contradiction se règle dans sa tête, et elle ne se voit plus.
La compétence n'est pas en cause. Un développeur peut faire un très bon PO.
Le risque est un biais de perspective : regarder le produit depuis ce qu'on sait construire, plutôt que depuis ce qu'il serait pertinent de construire.
La condition pour que ça marche est un vrai changement de posture, pas un cumul de casquettes. Concrètement : quand il travaille en PO, il ne parle pas d'implémentation, et il laisse l'équipe proposer les solutions.
D'où il vient : d'expériences réelles avec des demandes irréalistes, et du sentiment que la technique n'est pas prise au sérieux.
Ce que le rôle demande : le PO n'estime pas, il écoute les estimations. L'estimation appartient à l'équipe. Ce qu'il doit comprendre, c'est qu'une story coûte cher, pas pourquoi elle coûte cher.
| Le PO décide | Le PO ne décide pas |
|---|---|
| ce qui entre dans le backlog | comment c'est construit |
| ce qui n'y entre pas | combien de temps ça prend |
| l'ordre des éléments | ce qui tient dans un sprint |
| quand on arrête un produit | la qualité technique |
La colonne de droite est celle qui pose problème aux dirigeants. Un PO à qui on demande de garantir un délai fait un travail qui n'est pas le sien, et il le fait mal, parce qu'il n'a pas les éléments.
La responsabilité de la date passe par l'arbitrage du périmètre, détaillé dans « Estimer n'est pas s'engager ».
Les deux titres circulent, parfois pour la même personne. Une répartition courante : le PM regarde vers le marché, le PO regarde vers l'équipe. Le PM décide sur quel problème on se place, le PO décide ce qu'on construit cette semaine pour le régler.
Dans une petite structure, une seule personne tient souvent les deux. Les deux regards portent sur le produit, avec des horizons différents.