Par Eve Vinclair-Berkemeier pour Conférence Agile
Inexistant en théorie, on parle concrètement du Proxy Product Owner lors de la mise en place de certains projets informatiques. Nombreux sont les facteurs qui ont fait naître l’intermédiaire entre le(s) Product Owner(s) et l’équipe. Ces facteurs sont évoqués et discutés lors de la table ronde afin de faire émerger au fur et à mesure le rôle du PPO. Côté fun, je propose mon “Mister Patate version Superman”. Je note sur un paperboard les expériences et les suggestions des participants : le groupe peut choisir une définition lors de la discussion et, si l’une d’elle est retenue, on ajoute un élément vestimentaire à Mister Patate, dans sa volonté d’incarner Superman…
Je voudrais partager mon expérience avec des chef de projets qui se sont retrouvés PPO, avec ceux qui sont devant le dilemme et le désir d’agiliser leurs projets V, ou ceux qui sont simplement curieux – et adeptes, bien sûr, de Mister Patate!
J’adore échanger et discuter des projets agiles, en particulier les projets qui ont été difficiles à mettre en place. Le bénéfice est surtout pour Mister Patate… qui n’aura plus froid !
Max 10 personnes autour d’une table ronde :
- chefs de projets avec l’expérience d’un projet agile
- chefs de projets qui ont envie d’agiliser leur projets traditionnels
- curieux d’agilité, avec une connaissance des théories d’agilité
Complément d’article par Audrey Pedro pour Xebia
Il y a environ six mois, je rencontrais Xebia à propos d’un poste au contour flou de business analyst / product owner / interlocuteur métier / consultant fonctionnel pour les projets de Xebia Studio. Lors de cet entretien, nous tâtonnions dans une définition de cette fonction. Aujourd’hui encore, lors d’avant-ventes, nous prenons soin de bien expliquer ce rôle de business analyst / product owner / interlocuteur métier / consultant fonctionnel / proxy PO et surtout ce qu’il va apporter au projet. Après tout, le proxy PO ne connaît pas tous les métiers de la terre (qui pourrait prétendre ça ?) ! Alors comment peut-il être côté métier, et ce quel que soit le métier ?
Je vous propose de répondre au mieux à cette question, notamment au travers des missions auxquelles j’ai participé et qui m’ont permis de devenir proxy PO.
Le premier fait extrêmement marquant, et qui rend la description d’autant plus compliquée, est que ce rôle dépend beaucoup du projet, de l’équipe de développement et surtout du PO ou responsable marketing avec lequel je travaille. En effet, être proxy PO c’est faire en sorte que l’équipe de développement puisse travailler tranquillement, en toute sérénité. Une définition bien vague que je vais donc illustrer en relatant mon quotidien.
Pour commencer, j’écris ou j’aide à écrire des stories car le PO n’a pas le temps ou bien il n’a pas l’habitude de se positionner du côté de l’utilisateur. Je suis donc garante du backlog. Je fais beaucoup de backlog grooming, ce qui consiste à prioriser les stories, à les remettre à jour, etc. Et surtout, j’essaie autant que possible de préparer les inputs liés aux stories (graphes permettant de visualiser les écrans au tout début d’un projet, règles métiers par la suite, etc.). Ceci permet à l’équipe d’être plus sereine : nous savons où nous allons dans le sprint notamment. Il y a parfois des ratés mais l’intention est là 🙂
Je participe également aux ateliers avec le PO et d’autres intervenants du projet (l’ergonome, le service communication, etc.) afin de capturer les informations nécessaires aux inputs de stories mais aussi de faciliter les échanges.
Ensuite, je suis présente aux stands up — quand je le peux, car mon temps est partagé entre deux projets et c’est parfois compliqué… Mais il s’agit là d’un autre débat. Le stand up est très important pour réussir la bascule d’un projet à l’autre. Mais aussi et surtout, il est important pour l’équipe, qui en profite pour poser toutes les questions métier en réserve.
J’ai lu récemment un article remettant en question l’existence du proxy PO. L’auteur défend qu’il peut exister plusieurs PO, mais que le rôle de proxy n’existe pas. Il est vrai que Scrum ne définit pas ce rôle. Néanmoins, c’est un rôle qui émerge du terrain par un manque identifié. Les attributions du PO sont conséquentes. On parle souvent de « polymath ». Il faut alors trouver la perle rare : à la fois compétente dans le métier, mais aussi intéressée par les processus agiles et ayant le temps de porter toutes les responsabilités lui incombant. J’ai bien peur qu’il y ait souvent besoin de plusieurs personnes pour tout ça… Plusieurs PO ? Pourquoi pas, cependant il y a souvent un PO plus stratégique (vision stratégique, proche des stakeholders) et un PO plus « tactique » (gestion du backlog, du produit à court et moyen terme). D’où le terme de proxy. Certes ce rôle est peut être une béquille transitoire dans les organisations en phase d’apprentissage agile ou juste une variante plus réaliste du « Unbreakeable PO », super héro remplissant toutes ses tâches au mieux.
Quoiqu’il en soit, le rôle de proxy PO au sein de mes missions permet d’enrichir les interactions. N’est-ce pas plus important que de respecter Scrum by the book ? Il permet d’éviter certains écueils et, pour paraphraser un autre article de blog (très amusant par ailleurs), les concepts agiles doivent supporter des adaptations lors de leur mise en application afin de sauver l’agilité.
Pour conclure, en tant que proxy PO je suis le bras droit du PO et je me place donc dans les trous, les espaces vacants que le PO ne peut pas occuper par manque de temps le plus souvent, parfois par manque d’habitude. Parce qu’à force, les ‘je veux… afin de…’, j’en ai l’habitude !
