Les 5 signes pour discerner un faux PO

Faux PO ? Mais de quoi parles-tu ?

Avec l’essor de l’agilité en entreprises depuis quelques années, notre profession est en haut des classements des nouveaux métiers.

Cette tendance à fait exploser les recrutements.

Le problème c’est qu’avec un job relativement nouveau, peu connu des recruteurs et qui n’est pas encadré par une formation académique dédiée… on se retrouve avec des profils dits de PO qui ne le sont pas vraiment.

J’avoue avoir hésité à évoquer le sujet mais finalement je tiens à crever l’abcès et dire tout haut ce que beaucoup pensent tout bas.

Parmi nos rangs, il existe un pourcentage de faux POs.

Si vous êtes développeurs, designers… et que vous travaillez en relation direct avec un PO, je vous dévoile 5 signes qui doivent vous alerter.

1. Il est placé côté métier

Le grand classique ! Dans certaines grandes entreprises (et pas que) on place le PO coté métier.
En clair, plutôt que d’être assis avec son équipe et travailler en direct avec les devs, le PO est directement rattaché au département Marketing (par exemple).

Dans cette situation, le PO n’est pas fautif car ce n’est pas lui qui a mis en place la structure de l’organisation (il a quand même accepté le poste malgré tout).

On l’a mis là et il est assis dans un autre bureau entre le Manager SEO et le directeur Marketing.

Le problème c’est que même si le problème vient de l’entreprise qui n’a rien compris au rôle, cette situation n’est pas stable.

Le PO doit impérativement faire partie de l’équipe Scrum.
Si ce PO ne fait pas l’effort de faire comprendre l’incohérence à son N+1 et ne se rapproche pas de l’équipe, il y a un gros problème.

2. Il travaille avec un Proxy PO

Ce qui découle souvent de l’exemple 1 c’est la conséquence d’embaucher un Proxy PO.

Un proxy PO en gros c’est un middleman qui fait le lien entre le PO et l’équipe.

L’excuse tout trouvé pour embaucher un Proxy PO est que Monsieur le PO est trop débordé avec d’autres tâches et n’a pas le temps de s’occuper de son équipe car il est situé du côté métier.
Vous avez bien lu, il n’est pas disponible pour les développeurs (on croit rêver).

Du coup, le Proxy PO va combler le manque de présence du PO officiel et va être plus présent dans l’équipe Scrum. Il va faire toutes les tâches du PO (rédaction des users stories, participation aux cérémonies, facilitation…) sauf la priorisation du backlog.

En résumé, le proxy PO joue le rôle d’un vrai PO mais n’en a pas le titre (ni le salaire…).

Dit autrement il y a un faux PO en place et pour masquer l’imposture on a inventé un nouveau rôle qui n’existe pas dans la méthodologie scrum.

Tout va bien… on peut retourner bosser la conscience tranquille !

3. Il ne participe pas aux cérémonies

Encore un signe qui ne trompe pas c’est la phobie des cérémonies.

Daily, rétro voir meme sprint planning ou poker grooming (pour les cas extrêmes) sont régulièrement zappé par les faux POs.

Vous avez  2 types :

La phobie sévère :  Le faux PO ne participe jamais à certaines cérémonies. Il ne s’en cache pas. Cette personne semble ne pas comprendre l’intérêt de ces cérémonies et l’assume complètement. 

Après tout le Scrum c’est tellement Has Been, il faut évoluer dans la vie.

La phobie refoulée : Le faut PO montre sa volonté de participer aux cérémonies mais coïncidence, il fait l’impasse régulièrement par manque de temps.

Evidemment, il a de bonnes excuses. Il a toujours des choses à faire plus importantes que de parler à son équipe et prendre de l’information.

Après tout ce n’est qu’un sprint planning, on peut s’en passer 😉

4. Il ne parle pas le langage développeurs

Alors, j’en ai déjà beaucoup parlé, on n’a pas besoin d’avoir un background technique gros comme celui de Steve Wozniak pour devenir PO. 

Ceci dit, on n’accepte pas un job en Chine sans parler un peu le chinois.
Si votre PO ne fait pas l’effort de comprendre votre langage ou pire qu’il réinvente votre langage avec ses propres mots…. attention alerte.

Des indices ?

  • Confondre Java et Javascript 
  • Pensez que testeur QA ca vaut dire Testeur Question Answer
  • Ne pas faire la différence entre navigateur et OS
  • Croire que les chiffres des Story points sont des estimations en heures ou en jours
  • Convoquer les dev Backend pour estimer une story UX
  • etc..

J’en ai des milliers comme ça.

Si ce genre de cas vous arrive, soyez indulgent, on dit tous des bêtises à certains moments.

En revanche, si la personne n’a pas l’envie d’apprendre et ne se remet pas en question, tirez la sonnette d’alarme.

5. Il n’utilise pas les bons outils

Enfin pour conclure ce TOP 5, je dois parler des outils.

S’il y a bien un outil clé dans le métier de PO c’est l’outil de gestion de projet.
Il y en a des tonnes sur le marché et pourtant j’ai croisé des personnes qui me disaient ne pas en utiliser car ils les trouvaient trop complexes.

Alors, je veux bien qu’il y a une théorie qui raconte que l’on peut tout faire à partir d’un tableur excel mais faut pas pousser.

On impose pas un outil à une équipe entière juste parce que arrange une personne.
Des outils tels que Trello c’est très bien et plus simple qu’un outil comme Jira, mais du point de vue collaboration, bonjour les dégâts.

Faire les US et les burndown chart sur Excel c’est interdit en 2020.

A moins de cas extrêmes, où c’est l’organisation qui l’impose, aucun PO qui se respecte ne collabore avec son équipe avec des outils non adaptés.

Ce n’est même pas une question de prix, il existe aujourd’hui beaucoup d’outils gratuits.

Faux PO: La faute à qui ?

Dans la majorité des cas, ce que j’appelle des faux POs sont juste la conséquence de mauvais recrutements.

Un chef de projet Marketing ayant une appétence pour le digital et ayant collaboré avec une agence web dans le passé pour l’élaboration d’une landing page peut se retrouver du jour au lendemain PO par simple décision de son N+1 car la direction vient de décider de passer en agile.

En général ces profils se retrouvent propulsés dans un job qu’ils ne connaissent pas et doivent assumer des responsabilités qu’ils ignorent.

Ces cas sont plus fréquents que l’on ne pense.
Le manque de connaissance des ressources humaines d’une grande entreprise et l’urgence des directives aboutissent à des aberrations dans lesquelles les personnes nouvellement nommées ou engagées se retrouvent prises au piège et en souffre.

Le but n’est pas de juger ces personnes, je n’en ai pas le droit.
En revanche, j’invite les organisations qui recrutent les POs et qui n’ont pas d’historique dans ce domaine à approfondir le sujet et se faire accompagner.
Ne recrutez pas un PO parce qu’il s’agit d’un buzzword et que vous êtes soit disant agile.
Evaluez votre besoin et comprenez le rôle que vous voulez recruter.

9 Replies to “Les 5 signes pour discerner un faux PO”

  1. Je trouve votre justement un peu dur et je ne suis pas aligné avec vos arguments.
    1)Un PO confirmé passe toujours par une phase de PO débutant. Même s’il est propulsé il apprendra sur le terrain.
    2)Un PO non technique et issu des rangs du business, aura également des choses à apporter (pas grave si on ne distingue pas JS et JEE)
    3)Selon Scrum, un PO est garant de la vision et est responsable du backlog. Il peut tout à fait s’appuyer sur un ou plusieurs proxy PO qui auront la compétence fonctionnelle – notamment pour des solutions parfois complexes/techniques.

    1. Bonjour PO grincheux,

      Votre commentaire est bienvenue et offre une nouvelle perspective.
      Evidemment, dans ce court article, je ne jette pas la pierre à des PO débutants. Il faut bien débuter.
      Concernant les PO non techniques, je n’ai pas de souci avec cela, simplement je souligne juste que l’on ne peut pas rester sur ses acquis quand on collabore toutes la journée avec des devs.
      A terme, le PO risque d’etre rejeté par l’équipe s’il ne s’aligne pas sur leurs exigences. C’est cruel mais c’est comme ça. J’ai vu de nombreux exemples de POs coupés de leurs équipes car ils ne voulaient pas approfondir leurs expertises techniques.
      Enfin concernant le role des Proxy PO, je suis en désaccord avec vous. Si on besoin d’un proxy PO, c’est que le PO original ne fait pas correctement son boulot. Si le PO à besoin d’expertises techniques, il y a déjà les leads techniques qui sont là pour l’aiguiller.

      Excellente journée

  2. Bonjour,

    D’abord, merci pour toutes ces ressources !

    Ma question s’oriente sur le côté proxy PO. Que faire si le PO a trop de travail ? Prenons le cas d’une startup dont la masse salariale grossit rapidement, et notamment dans l’équipe technique. Je ne sais pas dans quel type d’entreprise vous évoluez, mais je pense que le cas des startups est à prendre à part. Par exemple dans celle où je travaille en tant que développeuse backend, nous sommes en phase de grosse refonte technique sur une grosse application, à ça se rajoutent la résolution de bugs, le développement de nouvelles features. Le PO est débordé car l’entreprise avance très très vite et il n’a pas le temps de tout faire dans les temps, même si ses méthodes de travail sont bonnes.

    Je pense que dans ce cas la présence d’un proxy PO peut être justifiée ? Je vous pose la question car la question se pose actuellement dans mon entreprise et je serais éventuellement intéressée par une évolution interne et passer de développeuse back à product owner.

    1. Salut Justine,

      Je ne pense pas que ce cas de figure concerne uniquement les startups. C’est un problème de charges de travail, pas de taille d’organisation.
      A mon avis, si ton entreprise à les moyens d’embaucher un proxy PO, pourquoi ne pas directement embaucher un autre PO et créer une équipe scrum dédiée uniquement aux nouvelles fonctionnalités ou au support clients (bugs…).
      Si ton PO est débordé c’est certainement qu’il a un manque de focus quelque part (priorités) et que l’on lui demande de faire le boulot de plusieurs équipes au lieu de se concentrer sur une seule mission.

      Bonne chance à toi,
      J’espère que ta boite te donnera ta chance 😉

      Julien

      1. Bonjour Julien, Bonjour Justine,
        Merci Julien, je partage tes points, et surtout le n°3. Pour le point 4, même si le PO n’est pas technique, je pense effectivement qu’il doit faire des efforts pour essayer de comprendre le langage des développeurs, faute de savoir le parler couramment. Les techs lui seront reconnaissants pour cet effort, et la confiance des techs envers le PO est capitale à mon avis.
        Pour Justine, je suis salarié d’une SSII Française, sous-traitant d’une grande entreprise Française, et PO pour cette entreprise, ce qui est une exception pour les règles de cette entreprise (je dois avouer que j’ai eu de la chance :-)). Si le PO n’a pas le temps, c’est qu’il ne sait pas prioriser, ou effectivement, comme le dit Julien, que 2 équipes sont nécessaires. Personnellement, je crois beaucoup à la complémentarité PO – SM – Tech Lead, et je pense qu’un proxy-PO dans ce trio ne servirait – au mieux – à rien. Les anos de prod peuvent effectivement prendre beaucoup de temps à un PO si le delivery s’est mal passé (suite aux pressions de la DSI pour livrer au plus tôt avec un contenu non négociable, par exemple, ce qui va à l’encontre de la démarche Agile, mais je suis bien placé pour savoir que ça arrive …). A mon avis se doit de voir ce qui se passe en prod et y mettre les mains le cambouis, mais il peut/doit se faire aider par l’équipe si le problème en prod sont trop nombreux, et augmenter la bande passante de l’équipe réservée à la prod, quitte à se battre becs et ongles avec la DSI s’il le faut.
        En résumé, un PO qui est trop occupé pour travailler avec l’équipe, c’est un PO qui : ne sait pas prioriser ET/OU ne sait/veut pas impliquer l’équipe pour l’aider ET/OU n’a pas le courage de remonter la problématique aux supérieurs/train … Je ne suis pas parfait, et il m’arrive de tomber dans ces travers, mais l’important est d’en avoir conscience et de savoir en sortir.
        Et concernant ton évolution, si tu sais prendre des décisions (bonnes ou mauvaises, l’avenir seul saura le dire), si tu sais faire confiance aux autres, et si tu sais tenir tête aux « chefs » pour le bien des utilisateurs et de l’équipe, vas-y fonce !
        Eric

  3. Très bonne article.

    souvent les mauvaises organisations mettent le faux PO avec un faux Tech Lead, dont ce dernier servira à la fois de tampon et à la fois de chef d atelier, en cherchant littéralement à faire avaler la pilule aux développeurs comme quoi ils devront accepter l inacceptable, comme l incompétence de ces derniers.

    Cela fini par créer un cercle vicieux

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *