Product Owner manager spécialiste ? Comment est-ce possible ?

Il arrive parfois que le PO soit Product Owner manager spécialiste, c’est à dire PO, mais aussi un manager, voir également un spécialiste. Cela pose quelques soucis dans le déroulement des projets en mode Agile. Il est tout à fait possible d’avoir ces compétences, cependant il est nécessaire alors savoir les utiliser aux moments opportuns.

Product Owner manager spécialiste, comment en arrive-t-on là ?

Lors de la mise en place de l’Agile dans les organisations existantes les fonctions et les rôles étaient déjà répartis de la sorte. Au changement d’organisation, au passage en SCRUM par exemple, le manager, par manque de confiance n’a pas voulu laisser la main à une autre personne. Il est donc toujours manager et a en plus pris la mission de Product Owner. Le manager en place veut peut-être aussi étendre son pouvoir à d’autres produits. A cela peut s’ajouter une dimension politique. Le manager s’est peut-être battu pour ce rôle, pensant que sinon il perdrait son titre de « responsable » ou pire son poste.

L’autre cas est le Product Owner qui a une « spécialisation ». Avant d’être manager il était architecte, designer, concepteur. Le nouveau Product Owner souhaite toujours être responsable de ce qu’il sait faire. Il l’est peut-être toujours et n’a pas eu la possibilité, ou ne veut pas se séparer de cette spécialité qui le rend indispensable dans l’organisation. Et même s’il n’est plus que « Product Owner » il faudra qu’il prenne bien garde à l’utilisation de ces compétences. Le cumul des trois compétences : Manager et Spécialiste et Product Owner, nous fait une belle carte de visite et rend les choses bien plus complexes.

Lors des transformations Agile c’est un cas typique de craintes des équipes « aurais-je toujours ma place ici ? ». La réponse est oui. Il « suffit juste » de regarder son rôle sous un autre angle et peut-être être prêt à faire des concessions quant à son « titre ». A ce sujet je vous recommande le livre « Qui a piqué mon fromage ? » de Johnson Spencer.

Mais bougre pourquoi donc cela peut-il poser problème d’être Product Owner manager spécialiste ?

Rappelons d’abord le rôle du PO. Il est là pour construire et partager la vision du produit. Cette vision qui va permettre de construire le produit en maximisant la valeur utilisateur. Pour cela le PO est en relation constante avec les parties prenantes et prend en compte les retours utilisateurs. Il rédige les User Stories adéquates. Celles qui maximisent la valeur apportée à l’utilisateur et les consigne dans le backlog produit. En tant que responsable du backlog : il le maintien à jour, il le priorise afin là aussi de maximiser la valeur apportée par le produit aux utilisateurs.

Le PO fait partie de la Team Scrum composée donc du PO, du Scrum Master et de la Dev Team. Le PO ne fait pas partie de la Dev Team. La Dev Team est composée de toutes les personnes qui vont permettre de réaliser le produit. Bien souvent des software Craftsmanship et, au besoin, des spécialistes.

Accompagnée par le Scrum Master, la dev team est responsable du « Comment », alors que le Product Owner est lui responsable du « Quoi ».

La Dev Team est autonome dans ses choix de comment réaliser le produit. De son architecture technique, la technologie utilisée, etc., et c’est important, cette autonomie permet d’obtenir l’engagement et la confiance.

Si un matin le PO arrive dans l’équipe et dit à tout le monde “c’est comme ça que tu dois faire, parce que je sais mieux que toi, je suis architecte technique, c’est moi le spécialiste”. Il est fort probable que cela engage des conflits. Le PO ne fait peut-être pas confiance à l’équipe. Et quand bien même, c’est bien ce que va ressentir la Dev Team. Si au début l’équipe essaye de se battre pour garder cette responsabilité, cela même qui la motive et qui lui laisse son autonomie, il est fort probable qu’au final elle baisse les bras et laisse cette responsabilité au PO.

En réunion de planning les développeurs pourront dire « je ne peux pas estimer. Ce n’est pas moi ai réfléchi à comment on va le mettre en place » ou « Je ne peux pas estimer par ce qu’il faut d’abord que le PO nous dise comment faire ». Et là l’erreur supplémentaire la plus importante serait que le PO estime pour la dev Team. Ce qu’il sera tenté de faire parce qu’après tout il est spécialiste.

En Review « On n’a rien à vous montrer parce qu’on n’a pas réussi à mettre en place l’archi que nous a imposé le PO ». Ou « Ben on n’a pas eu le temps de tout finir, on a embarqué trop d’US pendant le planning. C’était plus complexe que prévu ». Et en même temps ce n’est pas la dev team qui a estimée, elle n’a pas non plus eu son mot à dire sur comment réaliser le quoi. Comment pouvait-elle s’engager ?

Ainsi l’équipe s’est désengagée. Elle s’est déresponsabilisée et réalisera au minimum ce que le PO a dit, sans apporter sa valeur ajoutée. C’est pourtant cette force que permet les échanges constructifs et à toute la Scrum Team de progresser. Par ailleurs le manque de confiance ressentie par la Dev Team amènera des conflits. Ils rendront les relations plus difficiles et les réunions Scrum très compliquées.

Le PO est sorti de sa mission (“Quoi réaliser” pour apporter de la valeur à l’utilisateur) il est passé dans le comment.

Que dire du PO Manager, manager de l’équipe, peut-être directeur du département. Ce même manager qui a toujours sa porte de bureau fermée. Manager que l’on n’ose pas déranger, que l’on n’ose pas contredire. Que va-t-il se passer lors des meeting scrum ? Est-ce réellement parce que l’on est passé en Agile, en Scrum, que cela va changer tout seul ? D’un seul coup la Dev Team va-t-elle pouvoir parler franchement ? Va-t-elle dire qu’elle ne peut pas tout réaliser en un sprint ?

Peut-être que le Scrum Master, qui joue son rôle, tentera de protéger l’équipe (est-il peut-être lui aussi manager, ha ! Et peut-être aussi spécialiste ? Ha ha ! !), il y a de fortes chances alors que l’on entame une guerre de chef, un pilotage par la politique. Autant dire que là tout est réuni pour faire un beau produit qui ne sera pas de qualité et qui en plus n’apportera aucune valeur à l’utilisateur.

Cela aboutira à une frustration générale, on n’ose pas dire ! Il en résultera très peu d’engagement, comment lui dire non ? La qualité est alors médiocre. Il y a trop d’US à réaliser en un temps record. Alors il est nécessaire de faire des choix et comme souvent dans ce cas, c’est la qualité du code qui sera sacrifiée. On bâcle, on augmente le nombre de bugs et ont créée de la dette technique.

Et au milieu de ce Feydeau, se trouve une dev team se terrant au fond de son open space. Avec la peur qu’on lui reproche quelque chose. Parce que oui, il y a toujours un coupable, et on l’a trouvé ! On pourrait certainement utiliser les rétrospectives pour en parler. D’ailleurs les managers vous le diront « Tout se passe bien, en rétro on bosse bien, l’équipe est d’accord avec tous les axes d’amélioration que je propose, par contre les dev ne participent pas trop. Bon en tout cas au moins on n’y passe pas trop de temps et l’équipe est facile à manager ».

Certes, mais l’équipe a-t-elle eu l’autorisation de s’exprimer ? A-t-elle osée ? Et si elle l’a fait a-t-elle été écoutée ? Comment construire la confiance et la transparence ? Et comment coconstruire l’équipe et le produit ? Comment dans ce cas progresser ? Le fonctionnement est peut-être soi-disant Agile, en Scrum, avec des itérations, donc Agile. Mais non, il n’y a pas d’Agile ici, il n’y a que le nom. Au final, « pour de vrai », les rétrospectives se passeront mal. Les sprint review aussi et le manager dira alors « je ne comprends pas, l’équipe a tout ce qu’il faut pour réaliser un beau produit, les développeurs ont demandé à passer en Scrum. Nous y sommes. Pourtant ils n’avancent pas, ils ne délivrent aucune fonctionnalité, je n’ai rien à mettre en production, tout est buggé ».

Alors si on n’est pas Agile, que peut-on faire ?

Dans le cas présent, commençons par laisser de côté l’aspect management du Product Owner. Dans l’idéal le Product Owner ne doit être que Product Owner. Afin de construire un beau produit qui apporte de la valeur, il a suffisamment de missions à remplir pour s’occuper. Si ce n’est pas possible, alors quand il met sa casquette de PO il doit enlever celle de Manager et inversement. Il faudra peut-être du temps pour que la Team Scrum ne le voit que comme un Product Owner et non un manager. Cela dépendra aussi beaucoup de sa capacité à séparer les 2 rôles. Sa capacité à savoir quand être PO et quand être manager.

Le PO va devoir passer beaucoup de temps avec les parties prenantes, les utilisateurs et sponsors. Et ainsi maximiser la valeur du produit. Il est donc nécessaire que le PO comprenne l’importance de son rôle. Il est bien souvent difficile de mener à bien plusieurs missions à la fois. Le PO doit donc se recentrer sur sa mission principale et faire des choix.

Si le manager considère que sa mission principale est « manager » il ne pourra pas bien accomplir sa mission de PO et le produit risque d’en pâtir. Dans ce cas il est recommandé de proposer le rôle de PO à une autre personne, motivée par cette mission, qui en a les compétences (il peut être formé). Une personne en dehors de tout intérêt politique qui pourra se consacrer à 100% à son rôle de PO. Ainsi le manager ne sera que plus efficace en se consacrant lui aussi à 100% sur ses missions.

Dans le cadre du PO spécialiste, là aussi cela peut fonctionner. Le PO devra alors retirer sa casquette de spécialiste lorsqu’il est PO et inversement. Le PO doit comprendre ce qui est de sa responsabilité et ce qui ne l’est pas. Si le PO met la casquette de spécialiste, il n’est plus PO. Il fait alors partie de la dev team au même rang que les autres membres. Dans ce cas il participe aux choix et décisions prises comme n’importe quel autre membre, de manière participative, sans imposer. S’il se positionne correctement dans l’équipe il est fort probable que la dev team vienne naturellement le consulter, au besoin, en tant que spécialiste et non en tant que PO.

Le PO ne peut intervenir sur le comment sans brouiller les pistes et casser l’autonomie et l’engagement. Nous devons garder en tête que le PO est responsable du Quoi et la dev team du Comment.

Tous ces points convergent vers un sujet important, la motivation. L’Autonomie est un motivateur intrinsèque, c’est le sentiment à l’origine des actions, c’est la liberté de faire ses propres choix. Cette autonomie rend plus productif et permet de mieux encaisser des périodes de stress, elle améliore le bien être. L’autonomie permettra à l’équipe de s’engager plus fermement. L’équipe souhaitera alors augmenter ses compétences. Ce besoin de compétence est un motivateur intrinsèque. Vient ensuite le besoin d’appartenir à un groupe, d’y travailler pour une cause commune et de s’y sentir reconnu. Le PO participe à la cause, la reconnaissance vient du groupe, de la satisfaction des parties prenantes, des utilisateurs.

La motivation pousse au final à s’engager, à adopter des comportements et à persévérer. La motivation intrinsèque permet de réaliser des choses pour le plaisir et pour la satisfaction.  Si vous considérez vos équipes incapables de comprendre une problématique, vous créez une certaine frustration qui mène à la démotivation.

Le Product Owner ne devrait donc pas être aussi un manager et un spécialiste. Il ne devrait pas être l’un des deux non plus comme nous l’avons vu. Trop de compétences se mélangent. Rendant impossible d’en remplir une pleinement et surtout de remplir la mission principale du PO. C’est-à-dire faire en sorte que le produit apporte de la valeur à l’utilisateur.

Tout ce méli-mélo conduira à la démotivation de l’équipe et l’impossibilité de livrer un produit de qualité qui apporte de la valeur.