Product Owner et Scrum Master : deux redevabilités, une seule décision

Le Product Owner décide. Le Scrum Master ne décide rien.

Les deux répondent de quelque chose, aucun des deux ne commande personne. Mais l'un tranche et l'organisation doit respecter son arbitrage, quand l'autre n'a aucune décision à prendre, sur aucun sujet. Le titre qui contient le mot Master est celui qui n'a pas d'autorité.

Sur nos 2504 questions d'entraînement, 133 portent sur l'un des deux rôles, réparties sur huit certifications. Trois seulement les comparent directement. Les autres vous placent dans une situation où quelqu'un agit à la place d'un autre. C'est là que le point se gagne ou se perd.

Deux redevabilités, aucune hiérarchie

La Scrum Team compte trois redevabilités : un Product Owner, un Scrum Master, et des Developers. Le Scrum Guide 2020 précise qu'il n'y a ni sous-équipes ni hiérarchies, dans sa section Scrum Team.

Cette phrase règle plus de questions qu'il n'y paraît. Le Scrum Master n'est le chef de personne. Le Product Owner non plus. Aucun des deux n'encadre les Developers.

Le mot à tenir est accountable, que le Guide emploie pour chacun. Répondre de quelque chose n'est pas le commander. Le Product Owner répond de la valeur du produit sans écrire une ligne de code. Le Scrum Master répond de l'efficacité de l'équipe sans pouvoir l'ordonner à quiconque.

Cette absence de chef n'est pas une invention de Scrum. Le manifeste agile pose dès 2001 que les meilleures architectures émergent d'équipes auto-organisées, et qu'il faut faire confiance à des individus motivés. Le Scrum Guide ne cite pas ce texte, mais la parenté saute aux yeux.

C'est de là que vient la confusion, et c'est aussi ce qui la résout.

Ce que le Product Owner décide

Il est redevable de maximiser la valeur du produit issu du travail de la Scrum Team. Cela passe par une gestion efficace du Product Backlog, qui couvre quatre choses.

• Formuler et communiquer le Product Goal.
• Créer et exprimer clairement les items.
• Les ordonner.
• Faire en sorte que le backlog soit transparent, visible et compris.

Trois précisions comptent à l'examen, et elles tiennent toutes dans la section Product Owner du Guide.

C'est une personne, pas un comité. Ceux qui veulent changer le Product Backlog n'ont pas d'autre voie que de le convaincre.

L'organisation doit respecter ses décisions. Ce n'est pas une recommandation de courtoisie, c'est une condition posée par le Guide pour qu'il réussisse.

Il peut déléguer le travail, jamais la redevabilité. Un analyste peut rédiger et ordonner au quotidien, cela reste conforme. Le Product Owner demeure celui qui répond de la valeur produite et de l'ordre retenu.

Et il détient une décision que personne d'autre ne peut prendre : annuler le Sprint, quand le Sprint Goal devient obsolète. Seul lui, et c'est le seul motif prévu.

Ce que le Scrum Master ne décide pas

Il est redevable de deux choses : établir Scrum tel que le Guide le définit, et l'efficacité de la Scrum Team. Le Guide le décrit comme un véritable leader au service de l'équipe et de l'organisation.

Servir, pas diriger. Il n'assigne pas le travail, ne valide pas ce qui est produit, n'arbitre pas les choix techniques et n'ordonne pas le backlog.

Retenez le réflexe, il vaut pour une bonne moitié des questions de mise en situation. Dès qu'une réponse fait décider le Scrum Master à la place de quelqu'un, elle est presque toujours fausse. À la place des Developers sur le comment, à la place du Product Owner sur la valeur, à la place de l'équipe sur son organisation.

Une exception mérite d'être connue, parce qu'elle tombe en question difficile. Rien n'interdit au Scrum Master de travailler sur des éléments du Sprint Backlog. Il agit alors comme Developer et en assume les redevabilités. Celle qui porte sur l'efficacité de l'équipe, elle, ne se met pas en pause pendant ce temps.

Servir le Product Owner sans le remplacer

C'est ici que vivent les questions les plus intéressantes, et la règle qui les traverse est toujours la même.

Les items du haut de backlog arrivent trop vagues pour être sélectionnés. Le Scrum Master aide l'équipe à comprendre pourquoi des items clairs sont nécessaires, et propose des techniques de raffinement. Il ne les écrit pas et ne les valide pas.

Le Product Owner accepte tout et n'ordonne jamais par la valeur. Le Scrum Master l'aide à trouver des techniques d'ordonnancement, et rend visible l'effet de l'arbitrage manquant. Ordonner à sa place le priverait de sa redevabilité au lieu de l'outiller.

Il faut convaincre le Product Owner de traiter la dette technique. Le Scrum Master traduit la dette en effet mesurable : temps de test, anomalies subies par les clients, délai de mise en production. Le Product Owner arbitre alors en connaissance de cause. Un argument purement technique le laisse sans critère.

La règle sous ces trois cas tient en une ligne. Le Scrum Master agit sur ce qui alimente la décision, jamais sur la décision.

Elle vaut aussi pour les autres. Un manager qui juge mauvais l'ordre du Product Backlog n'a pas à le réordonner. Il peut mettre l'équipe en contact avec les utilisateurs, ou identifier les parties prenantes dont le retour manque à la Sprint Review. Il agit sur ce qui nourrit la décision, et la décision reste où elle est.

Un exemple, la même situation vue des deux côtés

Troisième jour d'un Sprint de deux semaines. Un incident touche un client important. Un directeur veut que l'équipe le traite tout de suite.

Ce que fait le Product Owner. Il renégocie le périmètre du Sprint avec les Developers pour y intégrer l'incident, et constate l'effet sur le Sprint Goal. Si l'objectif devient sans objet, il peut annuler le Sprint. Rien n'oblige à attendre le Sprint suivant, mais l'arbitrage lui revient.

Ce que fait le Scrum Master. Il rend les options du cadre visibles et réunit les bonnes personnes vite. Puis il veille à ce que la décision soit prise par celui à qui elle revient. Il ne tranche pas.

Ce que font les Developers. Ils disent ce que l'incident coûte et ce qu'il déplace. Personne ne décide à leur place comment le traiter.

Maintenant la version fausse, celle que les énoncés proposent en réponse plausible. Le Scrum Master répond au directeur que l'équipe s'en charge, et transmet la consigne.

Trois erreurs en une phrase. Il a décidé à la place du Product Owner, qui seul arbitre le périmètre. Il a décidé à la place des Developers, qui seuls organisent leur travail. Et il a laissé une demande entrer dans le Sprint sans passer par l'arbitrage prévu.

Ce que Scrum n'impose pas

La moitié des pièges vient de règles que le cadre n'énonce nulle part.

Le Scrum Master n'a pas à faciliter tous les événements. Il développe ses compétences de facilitation, mais l'équipe est plus efficace quand elle se les partage.

Il n'a pas à lever tous les obstacles. La plupart se règlent par la personne qui les rencontre. Il intervient sur ceux que l'équipe ne peut pas lever seule.

Aucun des deux n'a besoin d'être technique. Les Developers détiennent le savoir-faire. L'expertise du Product Owner porte sur ce qui apporte de la valeur, celle du Scrum Master sur Scrum.

Le Product Owner n'a pas à écrire tous les items. Il est redevable de la gestion du backlog, ce qui inclut leur création, et il peut en déléguer le travail.

Ni l'un ni l'autre n'est un chef de projet. Scrum ne demande ni gestion de périmètre, ni de budget, ni de délai, ni supervision des tâches.

« Product Owner » n'est pas un intitulé de poste. C'est un ensemble de redevabilités, qu'un Product Manager peut porter.

Reconnaître la question le jour de l'examen

Les énoncés vous mettront devant une situation où quelqu'un déborde. Deux questions suffisent le plus souvent à trancher.

Qui est redevable de ce dont il est question ? Et la réponse proposée respecte-t-elle cette redevabilité, ou la contourne-t-elle ?

• Le Scrum Master décide, assigne ou valide quelque chose : presque toujours faux.
• Quelqu'un veut changer le Product Backlog : il doit convaincre le Product Owner.
• Un comité veut décider du produit : le Product Owner est une personne.
• Le Product Owner délègue le travail : conforme, tant qu'il garde la redevabilité.
• Une hiérarchie désavoue le Product Owner : le cadre demande le contraire.
• Il faut annuler un Sprint : le Product Owner, et lui seul.

Une réponse qui protège l'auto-gestion des Developers, la redevabilité du Product Owner et le rôle de service du Scrum Master est presque toujours la bonne. C'est le même réflexe que sur les dix pièges les plus fréquents, et il se transporte d'un sujet à l'autre.

Questions fréquentes

Le Scrum Master est-il le chef de l'équipe ?

Non. Le Scrum Guide écrit qu'il n'y a ni sous-équipes ni hiérarchies dans une Scrum Team. Le Scrum Master est décrit comme un leader au service de l'équipe et de l'organisation. Il n'a autorité sur personne, et il n'assigne aucun travail.

Le Product Owner peut-il déléguer son travail ?

Oui, le travail. Rédiger des items, les ordonner au quotidien, tout cela peut être confié à quelqu'un d'autre. Ce qui ne se délègue pas est la redevabilité : le Product Owner reste celui qui répond de la valeur produite et de l'ordre retenu.

Le Product Owner peut-il être un comité ?

Non, c'est une seule personne. Il peut représenter les besoins de nombreuses parties prenantes dans le Product Backlog. Mais ceux qui veulent le changer doivent le convaincre, et l'organisation doit respecter ses décisions.

Le Scrum Master doit-il être technique ?

Rien ne l'exige. Son expertise porte sur Scrum et sur les techniques qui l'accompagnent. S'il choisit de travailler sur des éléments du Sprint Backlog, il agit alors comme Developer et en assume les redevabilités.

Qui peut annuler un Sprint ?

Le Product Owner, et lui seul, lorsque le Sprint Goal devient obsolète. C'est la seule circonstance prévue par le cadre, et elle reste rare. Un Sprint qui ne tiendra pas tout son périmètre n'est pas un motif d'annulation.

À retenir

• La Scrum Team porte trois redevabilités et ne connaît ni sous-équipe ni hiérarchie.
• Le Product Owner est redevable de la valeur, et ses décisions sur le Product Backlog doivent être respectées.
• Le Scrum Master est redevable de l'établissement de Scrum et de l'efficacité de l'équipe, sans autorité sur quiconque.
• Il agit sur ce qui alimente une décision, jamais sur la décision elle-même.
• Le Product Owner peut déléguer le travail, jamais la redevabilité.
• Une réponse où le Scrum Master décide à la place d'un autre est presque toujours fausse.
• Annuler un Sprint revient au Product Owner seul, et seulement si le Sprint Goal est devenu obsolète.

Ces distinctions se retiennent mieux en situation qu'en lecture. L'essai libre PSM I propose des questions originales avec correction immédiate, sans créer de compte.