Comment faire avec plusieurs product owner dans une même équipe ?

« Bonne question. Nous sommes 3 Product Owner dans notre équipe et je dois avouer que ça n’a pas toujours super bien fonctionné. Finalement ça n’a peut-être pas été une si bonne idée d’être plusieurs product owner sur le même produit. Laissez-moi vous raconter notre aventure. »

Petite histoire fictive de Martin, Product Owner

Toute ressemblance avec des faits réels est fortuite.

Bonjour, Martin, c’est moi. 
Je travaille dans un grand groupe pharmaceutique, auparavant j’étais Chef de projet MOA. Maintenant je suis Product Owner.

C’est vrai ça ? C’est une bonne question. Est-ce une bonne idée d’avoir plusieurs Product Owner dans une même équipe ? Nous sommes 3 product owner dans notre équipe et je dois avouer que ça n’a pas toujours super bien fonctionné. Finalement ça n’a peut-être pas été une si bonne idée d’être plusieurs product owner sur le même produit. Laissez-moi vous raconter notre aventure.

Si je me souviens bien nous sommes passés en Agile et en Scrum il y a moins d’un an, sans se poser la question quant à l’organisation des product owner. On était déjà 3 chefs de projet MOA à l’époque et nous sommes tous les 3 devenus product owner, nous imaginions que cela fonctionnerait pareil. En même temps je me demande si je serais resté dans l’entreprise si l’on m’avait dit qu’il n’y avait qu’un seul poste de PO pour le produit, qu’est-ce que j’aurais fait ? Je serais resté MOA ? Non, je ne crois pas.
Les RH m’auraient peut-être proposé de passer sur un autre produit, mais lequel ? Parce que franchement les autres produits sont voués à disparaître. Les RH m’auraient proposé un autre poste ? Mais je ne sais faire que de la gestion de projet, et puis c’est ce qui me plait.

Taille du produit

Il faut aussi reconnaître que le produit est très gros, il y en a dans tous les sens, un seul PO n’aurait pas pu tout gérer, surtout avec nos managers qui changent d’avis tout le temps et les équipes de dev qui n’y pigent rien. Franchement je me demande si j’aurais accepté de prendre seul ce rôle de PO. Et puis avec Jean, le plus ancien Chef de projet, je n’avais aucune chance d’avoir ce poste de PO. C’est le plus ancien et en plus il est dans les petits papiers de la Direction.

Forcément, il dit oui à toutes leurs demandes, nous après on devait trimer et on était toujours en conflit avec le CTO. Pauvre CTO d’ailleurs, je le comprends, il avait une pile de cahiers des charges en attente, ils étaient chiffrés certes, mais quand ses équipes auraient-elles pu les prendre en charge ? J’ai fini par comprendre sa technique, il attendait que ça râle fort sur un projet pour lancer la réalisation. C’est ainsi qu’on se retrouvait avec de vieux cahiers des charges de plus de 6 mois qui n’ont jamais été ouverts, tant mieux, parce que pour la plupart ils étaient devenus obsolètes, il aurait fallu les réécrire.

Passage à Scrum

Quand l’équipe est passé en Scrum on est donc tous restés dans une même unique équipe. Une bonne grosse équipe, 20 Développeurs, 3 Scrum Master, 3 PO. Nous avons commencé à travailler en sprint de 2 semaines, nous avons aussi créé un backlog et nous avons suivi les rituels Scrum. Au début cela a bien fonctionné, à chaque fin de sprint on a pu livrer de nouvelles features produit et je dois avouer que j’ai kiffé voir les Stakeholders et le métier contents d’avoir un résultat en seulement 2 semaines, même si ce n’était pas grand-chose.

Tout est rapidement devenu n’importe quoi.

Au bout de quelques mois le backlog était sens dessus dessous. Tout était devenu prioritaire. Chaque PO se battait pour faire passer ses Users Stories avant celles des autres. A chaque fin de sprint on ne livrait plus grand chose, l’équipe de développement ne réalisait que des brides de fonctionnalité, tout était partiellement commencé, ça allait dans tous les sens.

Chaque PO changeait les priorités en fonction du Stakeholder avec qui il travaillait, tous les PO touchaient à toutes les US dans le backlog. Franchement je ne savais plus où on allait. Je crois qu’à ce moment-là j’aurais assassiné Jean. Comment pouvait-il se permettre de toucher à mes US et à celle de ma collègue Zoé sans nous en parler. Et puis je ne parle même pas des réunions de planning où Zoé, Jean et moi nous écharpions pour faire passer nos US, elles étaient soi-disant toutes plus importantes les unes des autres.

Alors on a décidé d’ajouter des règles

Le PO à uniquement le droit de toucher à ses US.

On a également créé une réunion de PO pour préparer les sprint planning. Au moins on ne s’écharpait pas devant toute l’équipe, mais juste entre nous. Ces réunions de PO étaient interminables, nous arrivions presque toujours à un accord, on négociait dur pour arriver à faire passer quelques-unes de nos US. Les réunions de planning se déroulaient bien mieux. Par contre, pour les Démos, ce n’était pas encore ça.

Nous avions toujours un problème de livraison, de features pas abouties ou bien de features qui n’avaient rien à voir les unes avec les autres. A l’époque je crois que j’étais au bout de ma vie, j’avais honte du travail qu’on livrait. Si je n’avais pas eu des fenêtres anti suicide dans mon bureau, je serais passé par-dessus. Agile ! Franchement je l’ai maudit. Et Scrum n’en parlons pas. Au moins à l’époque, avant ce bazar, on faisait nos cahiers des charges tranquille, le CODIR s’occupait de les prioriser, bon des fois nous avions bossé dur pour rien, mais au moins je n’avais pas honte de ce qu’on livrait. Maintenant c’est comme si j’allais de l’avant sans voir vers où.

Introspection

Heureusement dans Scrum il existe un truc super : les rétrospectives. Même si Jean essayait toujours d’avoir le dernier mot, au moins on arrivait à parler et l’équipe a pu tester de nouvelles pistes. Zoé et moi n’étions pas seul face à Jean, toute l’équipe participait à son amélioration (de l’équipe hein !), les devs nous ont bien aidé là-dessus. Ce qu’ils nous disaient été parfois dur à entendre, mais au moins ils nous ont poussé à modifier notre fonctionnement.

Nous avons pensé organiser l’équipe des PO avec 1 PO et 2 Proxy PO (forcement Jean en PO et Zoé et moi en Proxy PO), mais j’avais lu à l’époque cet article « Le Proxy Product Owner est-il légitime ?« , et j’ai réussi à convaincre l’équipe que ça ne marcherait pas mieux. 
Alors on a décidé de continuer avec notre réunion de PO et d’aller plus loin en créant un « Comité de PO » et en le structurant. Il est bien connu que continuer à faire plus de la même chose donne plus de résultat ? A moins que je me trompe…

Comité de Product Owner

Donc qu’est-ce qu’on a fait ? (Elle n’est pas belle cette phrase hein.) Alors qu’a-t-on fait (pas beaucoup mieux non ?) Et bien nous avons créé notre Comité de Product Owner. Le Comité est devenu le responsable du produit. Sur le papier il n’y avait plus 3 responsables du produit, mais un seul. Théoriquement ce comité devait nous aider à nous aligner. Hé ! Ça va vous faire rire, mais rapidement on s’est effectivement retrouvé à faire plus de la même chose. Mais plus de ce qui ne marchait pas, en y ajoutant de nouveaux problèmes.

Nous (les PO) ne prenions plus aucune décision seul, les décisions étaient prises en comité uniquement. On écrivait nos US chacun dans notre coin et on les priorisait en comité. Dès qu’il y avait un changement dans le backlog, nous devions attendre le prochain comité pour décider des nouvelles priorités. Il nous est arrivé de faire des sprint plannings ou nous n’avions pas eu le temps de prioriser quoi que ce soit.

C’est la guerre des Product Owner

Et puis, rapidement les 3 PO ont dû s’aligner pour décider de la priorité ou de la pertinence d’une demande ou d’une US. Nous avons donc essayé de nous aligner sur une vision commune. Je ne sais pas pourquoi je n’avais pas pensé à cette vision avant. Peut-être par ce que j’ai lu le Scrum Guide entre temps. Nous aurions peut-être dû tous le lire vraiment avant de commencer à appliquer Scrum et à dire « ok on fait du Scrum, mais comme chez nous c’est comme ça alors faisons autrement », le fameux « ScrumBut ».

Seulement voilà, on a dû ajouter de nouvelles réunions de comité pour être suffisamment prêt en sprint planning. Du coup nous passions encore plus de temps en réunion où nous continuions à nous écharper pour prioriser nos features, même si nous avions théoriquement une vision commune. On n’arrivait pas à trouver de consensus. Les jours ou je n’en pouvais plus, je laissais Jean avoir le dernier mot, et ne parlons pas de Zoé qui avait totalement décroché je crois, ça a bien failli l’achever.

Déresponsabilisation

Cette « guerre » avec Jean nous a même amené à nous déresponsabiliser des US des autres PO, « Jean à pris la responsabilité de mettre cette US en prio, vois avec lui ! » ou « ce n’est pas mon US c’est celle de Jean ! ». Faut dire que ce n’était que justice parce que Jean démontait nos US dès qu’il le pouvait « ça c’est une feature de Martin, pfff ! Je ne comprends pas pourquoi on doit le faire. Vois avec lui ! ». Du coup personne n’était responsable de rien.
Nous avions toujours un problème de vision, en plus nous devions gérer l’égo de Jean, peut-être bien le nôtre aussi. Et puis il était hors de question que Zoé et moi laissions passer Jean « responsable » des Product Owner, je ne tenais pas à être son petit toutou.

Si je me souviens bien, nous avons eu à ce moment une rétro décisive. J’avais réussi à convaincre tout le monde de lire au moins une fois le Scrum Guide et à faire un peu de veille sur l’Agile en général. Il était clair que ce que nous avions testé ne fonctionnait pas. Avoir plusieurs PO sans alignement ne fonctionne pas. Plusieurs PO dans un comité non plus. On aurait pu ajouter un « Chef » dans le comité de PO, mais certainement pas Jean. Si Jean avait été un bon leader pourquoi pas, mais pas un chefaillon comme lui. Personne n’a osé le dire frontalement en rétro, mais tout le monde le pensait et Jean a fini par le comprendre. Il était bien conscient lui aussi qu’il fallait que l’on change radicalement notre fonctionnement.

Récapitulons

3 PO sur un même produit ça ne fonctionne pas naturellement.
Un comité de PO sans leader, sans vision, non plus.

Au lieu d’un comité avec un chef nous aurions pu tenter la piste d’un Product Manager, qui a la vision d’ensemble, est en lien direct avec les sponsors et à une dimension Marketing du produit. Mais personne n’a voulu prendre ce rôle, et puis notre produit ne se prête pas vraiment à ce fonctionnement. Il resterait alors 2 PO qui allaient devoir travailler ensemble. A deux il est peut-être plus facile de s’entendre, mais nous aurions probablement eu les mêmes problématiques. J’imagine, Jean Product Manager en tirant, Zoé et moi à ses bottes ! Non ça n’aurait pas fonctionné. Ou Moi Product Manager, Zoé et Jean à mes bottes ! Ouais ça c’est cool ! Non en fait pas trop, pas pour Zoé, et puis Jean n’aurait jamais supporté.
Et pour finir nous savons qu’un seul PO pour tout le produit ce n’est pas possible par rapport à notre produit qui est trop vaste. Sur un produit plus petit pourquoi pas, mais ce n’est pas notre cas.
Que nous reste-t-il ?

Solution

En fait la solution était sous nos yeux, 2 lignes plus haut. Le produit est trop gros ? Nous sommes 3 PO ? Divisons le produit en 3 ! Divisons pour mieux régner. Mais comment ?
Il y a en fait des fonctionnalités bien distinct sur le produit, et je dois avouer que si on regarde bien, Zoé, Jean et moi étions chacun plus à l’aise sur des sujets que d’autres. Jean connaît parfaitement le Back, Zoé a une bonne affinité avec le service comptable et moi je m’éclate avec le marketing. Zoooo ! On a donc découpé le produit en Features.
Une vision par feature, une priorisation par feature, des stakeholders par feature et, et, une dev team par feature. 

Au final on a changé pas mal de chose, on est maintenant 3 Scrum team, ou plutôt Feature Team !
Chacune est concentrée sur sa feature, nous ne nous marchons plus sur les pieds, chaque feature à sa vision, ses plannings, ses review, ses rétros.
Il a fallu que l’on aille plus loin pour coordonner le tout. Tous les 3 sprints, les 3 team font également une réunion de planning commun sous forme de story mapping ce qui nous permet d’avoir une vision macro de l’ensemble. Les teams réalisent aussi des review et rétros communes, histoire de continuer à aligner tout le monde et faire progresser cette belle cohésion. Chaque team est aussi Stakeholder des autres teams.

Vision

Il y a cependant rapidement eu un problème, les 3 PO devaient bien eux aussi aligner la vision sur le produit au global, on l’avait encore oublié cette vision. Surprise, Jean s’est effacé, bizarrement il n’avait plus la cote avec la direction, et puis de toute façon, l’équipe étant devenu autonome, plus besoin de jouer sur ce terrain-là, d’autant que la direction fait maintenant confiance à l’équipe.

Donc pour ne pas retomber dans les problématiques déjà rencontrées les teams m’ont naturellement choisi comme référent vision. Je suis donc une sorte de « Super PO » qui a une vision transversale du produit (je vois au travers !). Je ne suis le chef de personne, et puis je ne veux pas, c’est mieux comme ça, j’ai juste réussi à aligner tout le monde sur une vision commune, je suis un peu le leader de cette vision et j’arrive parfaitement à la partager avec l’ensemble des teams, avec Jean et avec Zoé.

Conclusion

J’espère que vous avez passé un bon moment à lire cette expérience. N’hésitez pas à réagir et à nous faire part de vos expériences. Il n’y a pas une bonne solution qui s’applique pour tout le monde. Il existe sans doute « votre solution » qui fonctionne pour vous par ce que vous avez votre propre culture. Ne copiez pas sans comprendre, inspirez-vous ! Et avant de triturer un framework comme scrum par exemple, commencez par l’appliquer tel qu’il est.