Dans le monde de l’agilité, nous parlons très souvent de rôle : Qu’est-ce qu’un Scrum Master ? Quelles sont les missions d’un Product OPS ? Quelles différences entre un Product Owner et un Product Manager ? J’en suis certain, vous avez déjà consulté ce type d’article ! En effet, ils nous apportent de précieuses informations et nous permettent d’être les témoins de l’évolution de notre profession. Mais bien qu’ils soient très intéressants, ces textes oublient souvent un paramètre important : le cadre dans lequel les équipes évoluent, car la nature de leurs rôles en dépend directement. Dans la grande galaxie de l’agilité, il existe de nombreux frameworks qui sont plus ou moins adaptés à certains types d’entreprises. En plus de Scrum, que nous connaissons tous, nous pourrions citer SAFe, Nexus, XP ou encore Kanban. Si tous ces modèles ont pour objectifs de créer des produits de façon itérative et incrémentale, ils n’utilisent pas tous la même méthodologie ni les mêmes rôles.

Une fois que nous avons posé cet état de fait, il est légitime de s’interroger sur les impacts de ces différents frameworks sur les rôles que l’on retrouve habituellement dans une équipe dite “agile”. Vous en conviendrez, nous ne pourrons pas traiter l’ensemble des frameworks dans le cadre de cet article. C’est pour cette raison que nous allons nous intéresser aux différences que l’on peut retrouver entre les Product Owners qui évoluent dans un environnement Scrum et ceux qui évoluent dans un environnement SAFe. Mais pourquoi ce choix ? La réponse est simple ! Premièrement, dans ce texte, c’est avant tout mes observations personnelles que je vais vous partager. Étant donné que Scrum et SAFe sont les frameworks que j’ai le plus expérimenté en tant que product owner, le périmètre de cet article s’est naturellement imposé

Dans un premier temps, nous nous intéresserons aux tâches et aux périmètres d’un product owner que l’on retrouve dans les frameworks Scrum et SAFe. Nous pourrons ainsi les comparer et saisir les différences qui existent. Ensuite, nous reviendrons sur la vision, plus générale, du produit dans ces deux types d’organisations, ce qui nous permettra de dégager les forces et les faiblesses de ces deux frameworks.

Le Product Owner dans le Framework Scrum

Commençons par le rôle d’un Product Owner dans une équipe Scrum. Habituellement, lorsque nous parlons de produit, d’agilité ou simplement de Product Owner, nous pensons directement à Scrum. C’est logique car, aujourd’hui, il s’agit du framework qui est le plus souvent utilisé par les équipes et qui bénéficie de la plus grande visibilité. Si ce framework a autant d’importance aujourd’hui, c’est parce qu’il a défini les différents rôles d’une équipe agile. En d’autre termes, c’est dans le framework Scrum que le rôle de Product Owner est défini pour la première fois : “Le Product Owner est la seule personne responsable de la gestion du Product Backlog… Le Product Owner est une personne, pas un comité… Pour que le Product Owner réussisse, toute l’organisation doit respecter ses décisions.”

Effectivement, dans une équipe Scrum, le Product Owner est responsable du product backlog et c’est lui qui priorise les fonctionnalités qui, selon lui, maximisent la valeur de son produit. Dans une équipe Scrum, le Product Owner intervient donc sur l’ensemble de la chaîne de création du produit. De la phase de Discovery à la validation des US en passant par le business plan, le Product Owner est partout et maîtrise son sujet de bout en bout.

Comme vous pouvez le voir sur ce schéma, dans une équipe Scrum, c’est le Product Owner qui va définir la vision de son produit en priorisant son backlog. Cette vision sera le reflet de sa compréhension des attentes et des besoins des parties prenantes et c’est lui qui constatera l’évolution de son produit au fil des sprints. Il est d’ailleurs le seul à pouvoir négocier de l’engagement avec son équipe pour chaque sprint. Vous l’aurez compris, dans une équipe Scrum, c’est le Product Owner qui a la maîtrise totale de son produit de sa genèse jusqu’à son décommissionnement.

Voici donc ce qu’il faut retenir du rôle d’un Product Owner dans une équipe Scrum :

Le Product Owner définit la vision produit et la diffuse auprès de l’équipe de réalisation.
Le Product Owner collecte les besoins des parties prenantes et définit la roadmap de son produit.
Le backlog produit est uniquement priorisé par le Product Owner.

Le Product Owner dans le framework SAFe

Nous avons vu ensemble que dans une équipe Scrum, le Product Owner a une vision à 360 degrés sur son produit. Mais va-t-il en être de même pour une organisation qui a choisi de travailler en SAFe ? Non, absolument pas ! SAFe est un framework dit “d’agilité à l’échelle”, ce qui signifie qu’il implique beaucoup plus de personnes et de rôles pour son bon fonctionnement. On retrouvera ce cadre méthodologique dans les entreprises qui subissent de nombreuses dépendances entre leurs différents produits. En plus de cela, SAFe est particulièrement intéressant pour les équipes qui comptent entre 50 et 150 contributeurs sur un produit. Vous l’aurez compris, nous sommes donc sur une toute autre échelle que Scrum qui recommande des équipes comprenant entre 3 et 9 membres. Avec SAFe, on est loin de la règle des deux pizzas pour nourrir une équipe ! Mais le schéma d’une organisation type SAFe vous permettra de mieux comprendre la différence avec Scrum.

Alors que Scrum concentre tous les attributs « décisionnels » au Product Owner, avec SAFe on remarque d’emblée que ce modèle organisationnel comporte plusieurs étages de responsabilité. Mais quelles sont les conséquences pour les Product Owners qui évoluent dans ce cadre ? C’est très simple ! Avec SAFe, les responsabilités de la gestion du produit sont séparées entre plusieurs rôles. La vision Business revient donc au Business Owner, la vision produit au Product Manager et, pour finir, la gestion d’une équipe au Product Owner.

Nous retrouvons donc le Product Owner au premier étage de la structure. Il n’est plus responsable du Product Backlog, mais d’un Team Backlog. Avec SAFe, c’est donc le Product Manager qui est chargé de maintenir le backlog produit. Mais quelles sont les différences ? Dans un environnement Scrum, il n’y a qu’un seul Backlog, même s’il y a plusieurs équipes. Bien que SAFe ne dispose que d’un seul Backlog Produit, chaque équipe dispose de son propre “Team Backlog”. Si cela vous paraît anodin, les impacts sur le rôle du Product Owner sont pourtant bien là car :

La vision produit est définie par le Product Manager et le Product Owner doit la diffuser au sein de son équipe.
Les enjeux business et la collecte du besoin sont traités par le Product Manager et le Business Owner.
Le Product Owner n’est plus responsable d’un produit, mais d’une brique applicative ou d’un périmètre bien défini et a une connaissance pointue de son sujet.
Il existe plusieurs équipes et plusieurs Team Backlog. La priorisation des développements de chaque équipe doit être négociée et planifiée par l’ensemble des Product Owners.

Pour résumer, dans un environnement SAFe, le Product Owner est le garant du Team Backlog de son équipe et participe à l’évolution de son produit en respectant la vision mis en évidence par le le product backlog géré par un ou plusieurs Product Managers.

Scrum vs SAFe : quels sont les avantages de ces deux frameworks pour le produit ?

Maintenant que nous avons défini les rôles, les responsabilités et les périmètres des Product Owners qui évoluent dans un environnement Scrum ou SAFe, il convient de s’interroger sur les forces et faiblesses de ces deux frameworks. Il est intéressant de rappeler que ces deux organisations s’appliquent à des équipes et/ou à des entreprises d’échelles complètement différentes et que par conséquent, ils ne répondent pas tout à fait aux mêmes objectifs.

Scrum

D’un point de vue produit, Scrum a de nombreux avantages ! En effet, avec cette organisation, l’ensemble de la vision, des décisions et des grandes orientations du produit sont définies par une seule et même personne : le Product Owner. Il est donc le point de convergence de toutes les personnes qui participent de près ou de loin à la création du produit. La principale conséquence de cette organisation, c’est la rapidité et la fluidité des échanges qui permettent de piloter le produit avec beaucoup de souplesse.

Avec Scrum, Il sera possible de “changer de cap” très rapidement si le Product Owner constate que ses hypothèses ne se sont pas vérifiées. Cette latitude, Scrum la doit surtout à des petites équipes et un nombre réduit d’interlocuteurs. Mais attention, pour un Product Owner, cette position peut être parfois fatigante sur le long terme, car il doit être sur tous les fronts. Il peut donc arriver que des Product Owners Scrum aient une connaissance fonctionnelle assez sommaire de leur produit.

SAFe

SAFe est une grosse machine ! Pour faire fonctionner ce framework, il va falloir beaucoup de personnes et une organisation à toute épreuve. Les échanges seront moins fluides, les décisions plus lentes et il sera très difficile de piloter le produit avec souplesse et rapidité. Les nombreux interlocuteurs ont pour principale conséquence d’alourdir la communication entre les différentes équipes. SAFe est un framework qui plaît souvent aux grandes entreprises, car il permet de donner une coloration agile à une organisation lourde avec de nombreuses étapes de validation.

Néanmoins, grâce au PI planning – durant lequel l’ensemble des équipes d’un même “train” planifie leurs 5 prochains sprints – il est plus facile d’identifier les dépendances entre les différentes équipes qui interviennent sur un produit. Pour résumer, SAFe permet de gérer les dépendances et de livrer assez efficacement de nouvelles fonctionnalités, mais cela se fera au détriment d’une certaine souplesse dans la gestion d’un produit. En réalité, les retours des utilisateurs ne sont pas aisément identifiables en raison du nombre d’interlocuteurs pour faire remonter l’information à la bonne personne.

Pour conclure

En ce qui concerne le rôle du Product Owner, nous savons que les deux frameworks ne lui offrent pas les mêmes niveaux de responsabilité et degrés de liberté. Scrum lui offre un aspect stratégique beaucoup plus important que SAFe. Pour autant, SAFe est une très bonne école pour un Product Owner junior. En effet, cette organisation lui permettra d’aller en profondeur sur les sujets fonctionnels de son produit tout en lui apprenant à gérer les dépendances. A contrario, un Product Owner plus senior pourra vite être frustré d’être écarté de l’aspect stratégique du produit sur lequel il travaille.

Article rédigé par Robin Jenicot