Différencier les rôles et responsabilités entre Product Owner et Scrum Master

Bien organiser l’équipe agile

Pour des questions évidentes d’efficacité il est important que chacun sache quels sont ses rôles et ses tâches. Ils doivent être définis en amont pour assurer la bonne cohérence de l’équipe et sa capacité à fournir les livrables dont elle est responsable. L’équipe agile comprend : une équipe de développement, un Scrum Master et un Product Owner.

Quel est le rôle du Scrum Master

Il travaille sur le « Comment ».
Il fait partie de l’équipe Scrum et s’assure que celle-ci travaille bien dans le respect de l’approche Scrum Agile. À ce titre il doit (entre autres) :

• Faciliter les événements Scrum (mêlée quotidienne, sprint planning, backlog refinement, etc.) et s’assurer du suivi des bonnes pratiques agiles (voire de leur implantation).
• Aider le Product Owner dans l’organisation du backlog pour les futurs Sprints.
• Veiller à la bonne communication avec l’équipe de développement pour régler au mieux les éventuels obstacles rencontrés et contribuer à la création de valeur.
• Protéger l’équipe des interférences extérieures qui pourraient venir perturber le bon déroulement du
• Encourager la mise en place de bonnes pratiques assurant un haut niveau de qualité tout au long du projet.

Le Scrum Master est comme la courroie de transmission entre l’équipe et le Product Owner puisqu’il aide les deux parties et joue un rôle de facilitateur. Il est le Servant Leader selon la terminologie officielle. C’est-à-dire que son rôle de leader ne consiste pas tant à donner des ordres sur qui doit faire quoi, mais plutôt de faire preuve de leadership afin de faciliter le travail d’équipe et la collaboration pour que le travail soit bien fait.

Une des difficultés du Scrum Master est donc de réussir à se faire respecter et entendre de l’ensemble des parties prenantes, alors qu’il ne joue pas un rôle de gestionnaire.

Quel est le rôle du Product Owner

Il travaille sur le « Quoi ».
Le PO fait lui aussi partie de l’équipe Scrum. En tant que client (ou représentant du client) il est responsable du produit qui va être développé, son rôle est fondamental car il doit en avoir une vision claire et précise (quelles sont les attentes clients, comment le produit va-t-il être utilisé, quelle est la valeur ajoutée, quelles sont les frictions…). Dans le cas contraire, il risque l’éparpillement (des efforts, des fonctionnalités, des ressources, etc.) et donc de ne pas avoir un produit final qui réponde aux besoins. C’est pourquoi, lors du développement, le PO doit (notamment) :

• Veiller à l’organisation du backlog et à sa priorisation, de façon continuelle puisqu’il n’est pas statique.
• S’assurer de la bonne compréhension des demandes par l’équipe.
• Réviser chaque livrable de chaque itération.
• Rendre des comptes aux parties prenantes (ses clients) sur l’avancement et les changements.
• Veiller à la livraison en temps et en heure du produit, dans le respect des requis.

Quels sont les risques quand les rôles sont mal définis – ou mal tenus

Le Scrum Master accompagne l’équipe à chaque étape du processus de développement pour qu’elle soit la plus efficace possible dans le cadre agile ; là où le Product Owner s’assure d’avoir une vision claire du produit et du besoin client auquel il répond.

Chaque acteur doit donc respecter le rôle qui lui est confié pour travailler en bonne intelligence. A contrario si chacun travaille dans son coin il est peu probable que les piliers Scrum seront respectés (transparence, inspection et adaptation) et que le résultat obtenu soit celui escompté.

Il existe un autre risque : des rôles mal définis. Ou plus exactement quand le Scrum Master ou le Product Owner déborde de son rôle.

Si le Scrum Master agit aussi en tant que Product Owner il risque de mal guider l’équipe de développement car il n’a pas l’accès direct aux besoins clients. Le produit final n’apportera donc pas la valeur ajoutée attendue.

Si le Product Owner empiète sur le rôle du Scrum Master il risque de freiner l’innovation au profit d’une livraison accélérée. Il aura aussi tendance à pousser l’équipe de développement à en prendre plus qu’elle ne peut lors des Sprints. Et, cerise sur le gâteau, à plus contrôler qui fait quoi pour forcer l’avancement, contredisant ainsi tous les principes Scrum… et l’harmonie de l’équipe. Ce faisant, il met à risque ses livrables.

En conclusion

Si les frontières sont mal définies entre les rôles au sein de votre équipe Scrum, c’est qu’il est temps de les préciser. Relire les règles du jeu du Guide Scrum , organiser une rencontre, rappeler les rôles et obligations respectifs, organiser du mentorat, suivre des formations… sont autant de mesures simples qui profiteront à tous.

Pour aller plus loin : 

 Image Deepmind pour Unsplash