Lourde charge est la mission du Product Owner dans Scrum. Elle est compliquée en termes de responsabilités sur le produit à développer et peut entraîner la centralisation d’un certain nombre de décisions.
Si l’on se réfère au modèles organisationnels classique de type Waterfall ou cycle V, un tel poste n’existe pas. Cependant je vais le comparer ici au chef de projet qui représente une autre forme de centralisation.
Dans Scrum, le Product Owner est une personne unique, en charge de manager efficacement le Product Backlog afin d’y traduire sa vision du produit, vision du produit qu’il se doit de construire dans une compréhension fine des besoins métier des clients qu’il représente.
C’est sur cette base que le PO insuffle sa vision auprès de l’équipe au quotidien. Il se doit pour cela d’avoir des échanges régulier avec ces derniers et être autonome dans la prise de décision sur le produit. Pour avoir ce pouvoir de décision le Product Owner doit être dans une relation de confiance avec le client.
Dans nos approches non agiles, le chef de projet se doit aussi de comprendre les enjeux et besoins métier. Il travaillera sur la base des spécifications fournies (Cahier des charges / URS) par la MOA (maîtrise d’ouvrage) et des échanges qu’il a avec cette même MOA, à la conceptions des spécifications fonctionnelles et techniques (FDS et TDS).
Ils seront par la suite utilisés comme base de référence pour l’engagement contractuel ainsi que la conception du projet sous la responsabilité du chef de projet. Ce contrat et ces documentations servent de garde-fou, c’est le bouclier de notre super héros chef de projet. On a ici une relation purement contractuelle.
Il faut s’avouer que trop souvent les zones d’ombre de ces documentations, qui se veulent exhaustives mais ne le sont jamais totalement, sont exploitées par les chefs de projet en manque de temps ou dans l’incapacité de livrer des solutions qualitatives, pour se protéger dans leurs manquements.
«
<En aparté>
-Non c’est marqué nulle part…
</En aparté>
<Au téléphone>
</Au téléphone>
»
Je caricature ici, mais l’on a tous vécu une situation semblable lors de projet waterfall. Cette situation est bien évidemment évitable si le chef de projet entretient une relation basé sur le retour utilisateur avec ses client. Cela dépendra de la façon de travailler de chaque chef de projet ou de son temps disponible à consacrer à ses utilisateurs et inversement. On constate que c’est rarement le cas et l’on fait souvent face à un certain “effet tunnel”.
Dans certaines applications de Scrum, le Product Owner se retrouvera parfois loin des utilisateurs ou parties prenantes gravitant autour du projet. On voit d’ailleurs régulièrement dans les projets la présence de proxy PO ou assistant PO accentuant cette distance.
Dans ses cas là, où les utilisateurs sont trop distants du projet et non présents aux démos lors des Sprint Review, on crée selon moi des risques sur la conception du produit. On attend du Product Owner d’être un super héro connaissant tout sur le projet et prenant des décisions de façon unilatéral. Ce qui peut être aux utilisateurs naturel et donc non exprimé (ou tout simplement parfois oublié), ne l’est pas universellement et l’on met ici le Product Owner dans la même situation que nos chefs de projets.
Si l’on revient à l’exemple de notre table, certains pourront potentiellement reprocher au Product Owner de n’avoir pas pensé à préciser que les pieds de la table doivent être en dessous et ce, même si les utilisateurs ou les parties clientes n’ont jamais mentionné ce détail, « parce qu’il en va de soi » et parce qu’elle n’étaient pas présentes lors du développement du produit pour faire les retours appropriés.
Scrum permet de décentraliser l’intelligence de création d’un produit du chef de projet vers l’intelligence collective de l’équipe de développement. Scrum n’apporte cependant pas de solution structurelle à l’importance d’une collaboration étroite entre le Product Owner et les utilisateurs ou le client (tout comme se le doit un chef de projet). C’est donc un point sur lequel il faut être vigilant en tant que Scrum Master.
A la différence des approches contractuelles où le chef de projet est protégé par le contrat, le PO ne l’est pas, ce qui rend ici la tâche de ce dernier d’autant plus périlleuse de mon point de vue.
Il est du rôle de l’équipe de développement de supporter et questionner le Product Owner sur ses décisions et elle est la plus à même de le supporter quand aux questions de conceptions. Elle peut être d’autant plus efficace dans son support au Product Owner si elle est en contact avec les utilisateurs, si elle possède une compréhension du contexte business, des notions transverses de marketing produit, d’étude de marché etc… Et donc si elle apporte de l’intelligence collective sur la vision du produit.
Scrum définit la Development Team comme “cross-functional”, et formalise qu’il fait aussi partie de ses tâches d’assister le PO pour le Raffinement du Product Backlog. « Refinement usually consumes no more than 10% of the capacity of the Development Team.» Ne sous estimons nous pas le périmètre de cette interdisciplinarité au seules compétences nécessaire à la production ainsi que le support que doit apporter la dev team au PO ?
Il me semble primordial que la Scrum Team échangent aussi avec les utilisateurs finaux, il faut travailler à l’élargissement de ses compétences afin d’être le soutien qu’elle peut être. Je tiens cependant à préciser qu’il faut être vigilant aux demandes cachées que les utilisateurs peuvent faire auprès de l’équipe de développements et ne pas contourner notre PO.
Il est central que les utilisateurs et le client soit activement impliqués tout au long de la conception du produit. Dans le cas contraire on risque de reproduire les mêmes problématiques que celles liées aux approches de projet classique et de rendre la mission du Product Owner intenable.
