Press "Enter" to skip to content

Le “chef de projet nouvelle génération”

Comment ai-je fait pour parler de “MOE et MOA” dans une description du Product Owner ???

Le “Product Owner” collecte les besoins fonctionnels, puis formule ou complète les spécifications fonctionnelles. Enfin, il les soumet à l’équipe de développement et s’assure du bon suivi. Il effectue d’ailleurs la recette pour s’assurer de la bonne communication entre MOE et MOA.

Ce Product Owner est clairement un chef de projet déguisé.

Donc c’est mal ?

Est-ce que, pour autant, ce Product Owner-là est en contradiction avec le rôle défini dans le Scrum Guide ?

Et bien, pas forcément. Tant qu’il n’interfère pas directement avec le fonctionnement de l’équipe de développement, on pourrait dire que c’est compatible avec le Scrum Guide.

Bon, ceci dit, un focus plus important sur la valeur des éléments du backlog ne ferait pas de mal…

Le Product Manager

C’est quoi la différence entre Product Owner et Product Manager ?

Quelle différence entre PO et PM ? Des éléments de réponse dans cette vidéo de Scrum Life : https://youtu.be/pSIYgV8_j9E

Cette question est récurrente et pourtant, la réponse n’est pas évidente à trouver… Pour la bonne et simple raison qu’il n’y a pas vraiment de différence entre les deux !

  • Product Owner est un nom qui a été introduit par le framework Scrum.
  • Quand on lit le Scrum Guide, on se rend compte que tout ce que doit faire le Product Manager devrait être idéalement pris en charge.

En résumé, un bon Product Owner Scrum est aussi un Product Manager !

Une question de contexte

La dynamique d’une équipe est spécifique à cette équipe.

Chaque équipe va trouver son propre mode de fonctionnement, qui sera adapté à son contexte au sens large :

  • Type de projet ou produit
  • Constitution de l’équipe : nombre de personnes, répartition des compétences
  • Fonctionnement de l’organisation
  • Clients
  • Caractères de chacun

À partir de là, l’écart entre la théorie des rôles et la pratique des tâches à faire est comblée de manière ad hoc par l’équipe.

Exemple : pertinence réduite du PO au quotidien dans l’équipe de développement

Imaginons un projet très technique pris en charge par une équipe de développement nombreuse, le tout dans une organisation moyennement Agile.

L’équipe va naturellement glisser vers une prise en charge grandissante du produit par l’équipe de développement :

  • Le PO a une valeur ajoutée minime puisque le projet est très technique
  • L’équipe de développement étant nombreuse, le PO ne peut pas suivre la cadence s’il ne “lâche” pas une partie de la gestion de backlog
  • D’autant plus que le PO est déjà très pris par la gestion de l’organisation : expliquer et justifier les priorités, définir et maintenir une vision pour l’équipe, communication au sens large

Cette équipe fait donc le choix — consciemment ou inconsciemment — de déporter au maximum le Produit dans l’équipe de développement.

Finalement, ce Product Owner s’écarte complètement de la vision “chef de projet nouvelle génération” pour devenir plutôt Product Manager — qui est une dimension à part entière du rôle de Product Owner au sens Scrum. Dans cet exemple, son rôle principal n’est pas de spécifier ce qu’il y a à faire, mais bien de donner une vision à l’équipe de développement et de les laisser gérer la suite.

Ma vision de l’enjeu du rôle de Product Owner

J’aime bien promouvoir l’idée que le Product Owner est le Coach Produit de l’équipe de développement.

Est ce que le Product Owner teste ? Un débat intéressant dans cette vidéo de Scrum Life : https://youtu.be/EvjVG56pMV0

Ou que le Product Owner n’est pas là pour tester à la place de l’équipe de développement.

J’aime bien rappeler qu’un monde s’ouvre au-delà de Scrum, le monde du Produit, notamment avec le Lean Startup, et que l’équipe doit se focaliser avant tout dessus. Et qui mieux que le Product Owner pour en être l’acteur principal ?

Mais alors, est-ce que c’est toujours un Product Owner ?

Peut-être, peut-être pas.

Est-ce que c’est grave ? On s’en fiche des noms.

Imaginons que le “produit” soit complètement pris en charge par l’équipe de développement. Franchement ce serait pour le mieux ! L’équipe de développement doit bel et bien s’approprier le produit. Et un développeur avec une vision produit est un meilleur développeur !

Le bon développeur, plus qu’un codeur

Skillz = coding + tests + produit

jp-lambert.me

Pour moi, je vois cette situation comme un Graal, un objectif peut être pas atteignable mais qui mérite d’être un objectif noble dont on se rapprocherait en permanence.

Un Product Owner différent en fonction de la maturité de l’environnement

Finalement, un peu comme pour le rôle de Scrum Master, on a différents types de Product Owners pour différents environnements. Par environnement j’englobe ici aussi bien la maturité organisationnelle et technique de l’équipe que celle de l’organisation autour de cette équipe :

  • Dans un environnement peu mature, l’équipe tirera parti d’un Product Owner qui pense production plutôt que produit : besoins clairement définis, recette, bouclier de l’équipe vis-à-vis de l’organisation, communication, gestion des releases…
  • Dans un environnement qui tourne, l’équipe tirera parti d’un Product Owner qui se donne à plein dans le rôle de Product Manager : analyse de marché, valeur métier, stratégie de prioritisation du backlog, Lean Startup…

Il n’y a pas de mauvais Product Owner ; seulement des Product Owners inadaptés à leur contexte !

Laisser un commentaire

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

Top