Le Product Owner et le Scrum Master (désignés par les initiales “PO” et “SM” dans la suite de l’article) sont deux rôles classiques de l’agilité : bien qu’à la base créés dans le cadre de la méthodologie Scrum, ces rôles ont maintenant évolué jusqu’à représenter à eux seuls toute une philosophie de développement logiciel, débordant parfois sur un imaginaire peuplé de montagnes de post-its et de démonstrations épiques.
Dans l’idéal, le SM et le PO forment un binôme de choc permettant à une équipe de développement d’embrasser la philosophie “agile” rapidement, de prendre en main son domaine de responsabilité et de construire le bon produit de la bonne manière.
C’est pourtant loin d’être toujours le cas, c’est pourquoi nous proposons cet article destiné à tout membre d’une équipe agile souhaitant améliorer la collaboration entre SM et PO.
Pour aller plus loin : découvrir la différence product manager vs product owner
Ce à quoi ne doit pas ressembler la collaboration SM - PO
Historique du Scrum Master et du Product Owner
Initialement décrits dans le guide de Ken Schwaber et Jeff Sutherland, les rôles de SM et de PO ont pour but d’encadrer une équipe fonctionnant selon la méthodologie Scrum. À la différence du PO qui est un métier à part entière et permanent dans l’équipe, le rôle de Scrum Master peut être endossé par tout membre de l’équipe, sauf par le PO. Quoi qu’il en soit, ces personnes doivent faire en sorte que l’équipe fonctionne bien. En résumé :
- Le Product Owner s’assure du fait qu’on construit les bonnes fonctionnalités, dans le bon ordre
- Le Scrum master est garant du bon fonctionnement de l’équipe ainsi que du respect de la méthodologie adoptée par l’organisation
Ces rôles théoriques sont bien jolis, mais mais nous remarquons de manière récurrente dans nos missions que cette collaboration peut vite se complexifier en fonction de quelques contextes que nous allons vous détailler au fil de cet article.
Quatre situations classiques où les rôles SM ou PO ne sont pas respectés
-
Quand les périmètres de responsabilité du SM et du PO ne sont pas clairs
Un des problèmes récurrents que nous rencontrons est la mauvaise définition des rôles de PO et SM. Cela survient par exemple lorsque, dans le cadre du passage d’une entreprise en “mode agile”, des postes de PO et de SM sont systématiquement dispatchés dans chacune des équipes de développement.
Notre proposition :
Focalisez vous sur la définition des postes que nous vous proposons ci-dessus, et effectuez le diagnostic suivant lorsqu’il y a un flou entre le PO et le SM sur la responsabilité d’une ou plusieurs tâches :
- si la tâche en question est en rapport avec le respect de Scrum et l’autonomie de l’équipe, c’est au Scrum Master de s’en occuper
- si la tâche est en rapport avec le respect de la roadmap ou bien la qualité de ce qui est livré chaque sprint, c’est au Product Owner de s’en occuper
Attention, cet arbitrage est parfois difficile à opérer. Par exemple : qui s’occupe de la mise en place de l’automatisation des tests fonctionnels ? Cela touche à la fois à l’autonomie de l’équipe et à la qualité des releases. Nous pensons ici que c’est au SM de se saisir du sujet et de collaborer en bonne intelligence avec le PO, car bien que touchant directement à la qualité des releases, l’automatisation des tests permettra à l’équipe de gagner en autonomie sur la gestion de la qualité de ses releases sur le long terme.
Quand l’équipe n’a pas compris le principe de Scrum
Autre symptôme d’un passage soudain en “mode agile” : l’incompréhension des équipes de développement vis à vis de Scrum. Une conséquence classique de cette situation est l'émergence de discussions axées sur la partie cosmétique des changements, et notamment liées à la perte de temps causée par les rituels agiles (“Le daily ça ne sert à rien”, “Pourquoi on chiffre en points ? C’est infantilisant”, etc.)
Notre proposition :
La philosophie du Shu Ha Ri est tout à fait compréhensible d’un point de vue théorique. Dans la pratique cependant, ce concept est parfois utilisé sans prendre la peine d’installer un espace de discussion et de comprendre les vrais besoins de l’équipe.
Le Scrum Master doit se poser les questions suivantes : quel est le rapport de l’équipe avec le business et les stakeholders ? Quelle est la fréquence des MEP ? À quel point l’équipe est-elle pluridisciplinaire ?
Tous ces facteurs seront cruciaux pour adapter les rituels à l’équipe dès le début.
Cela demandera plus d’effort, mais il sera plus efficace de comprendre un minimum les besoins de l’équipe avant de fixer les cérémonies plutôt que faire un Scrum “by the book” bête et méchant en utilisant la rétrospective comme opportunité de levée de boucliers de la part de l’équipe (ce qui peut ne jamais arriver, ou arriver tardivement si l’équipe pense que c’est normal de souffrir car “Scrum c’est horrible”).
Quand le Product Owner n’est pas responsable des tâches techniques de son équipe
Il peut arriver que le PO d’une équipe soit dispensé de tâches techniques : dans ce cas, on a souvent un backlog divisé en deux flux parallèles : des user stories fonctionnelles d’un côté, des tâches techniques de l’autre, avec une allocation de points pour chacun des deux flux.
Nous pensons que c’est une mauvaise pratique.
Notre proposition :
Si vous rencontrez cette situation, votre équipe doit penser ou bien constater que le PO n’est pas assez intéressé par les aspects techniques du backlog, et c’est en effet un problème ! Il est absolument nécessaire que le PO soit réceptif aux problématiques de l’équipe, et soit capable (du fait de sa légitimité dans l’équipe et de ses compétences) de les prioriser avec l’équipe.
- D’une part, le PO doit comprendre ces “tâches techniques” et ne doit pas voir ces tickets comme une menace à son “backlog fonctionnel”.
- D’autre part, l’équipe de développement doit réfléchir “outcomes” et donc se mettre dans les baskets de son PO lors de la réflexion sur comment améliorer le produit : qu’ont les clients ou l’équipe à y gagner ? Quels sont les risques à ne pas faire cette tâche technique ?
Il n’est pas recommandé de séparer dans la capacité du sprint tâches techniques et tâches business / fonctionnelles : cette priorisation doit être effectuée au sein du même flux de user stories, et un arbitrage doit être demandé au PM ou aux stakeholders en charge du périmètre.
S’il est avéré que le PO présente des lacunes concernant les problématiques techniques, il faut le former en conséquence. Comme cette tâche concerne l’autonomie de l’équipe, le SM sera responsable de la montée en compétence.
Pour aller plus loin : découvre la formation product owner et la formation product manager
Quand l’équipe est mature et que le SM se tourne les pouces
Dans le cas où le rôle de SM est systématisé dans toutes les équipes de développement, on peut parfois le voir s’orienter vers des activités de support de l’équipe (commander des serveurs, faire de la documentation, peaufiner les supports de user stories, relire les commits des développeurs, …) plutôt que de revoir son degré d’implication dans l’équipe, et changer potentiellement de positionnement dans l’entreprise.
Notre proposition :
Une équipe autonome livrant de la qualité qui n’a pas de SM attitré, ce n’est pas choquant. En effet, si les processus sont déjà bien huilés et que tout se passe bien, pourquoi ajouter un rôle à plein temps qui serait superflu ?
Par contre, si des dysfonctionnements tels que des sprints jamais terminés, ou des développeurs ne comprenant pas le sens du travail qui leur est demandé sont constatés, c’est qu’il faut un SM pour aider l’équipe à gagner en maturité. Il arrive que le PO prenne ce travail en charge (mauvaise idée), ou bien qu’un développeur de l’équipe se saisisse de l’affaire (ce qui peut être une bonne idée si la charge de travail n’est pas trop forte).
L’objectif du SM sera de clarifier les tâches qui ne sont pas effectuées et d’aider l’équipe à faire en sorte qu’elles le soient d’un point de vue pérenne, plutôt que de se substituer à ces rôles manquants.
Petit palmarès de questions que le SM peut être amené à se poser :
- La documentation est-elle bien écrite ?
- La QA est-elle convenablement effectuée ?
- Les membres de l’équipe passent-ils bien leur sprint à faire ce pour quoi ils ont été embauchés ?
- Les relations avec les Stakeholders et les autres équipes sont-elles saines ?
En ce qui concerne l’animation des rituels au jour le jour (daily stand-ups, démonstrations, rétrospectives, groomings), ce rôle peut être tout à fait tournant dans l’équipe car il ne demande pas de compétences particulières (à part un minimum d’aisance à l’oral).
En conclusion: des équipes auto-organisées avant tout
Cela ne vous aura pas échappé, la résolution de ces situations est toujours rendue possible par l’écoute et la volonté de rendre des équipes autonomes et efficaces.
Bien qu’indispensable à un certain point, le passage à l’échelle de l’agilité accroîtra les chances que les dysfonctionnements cités dans cet article apparaissent dans vos équipes. Si tel est le cas, il est important de garder en tête qu’un cadre méthodologique - même s’il est rassurant et qu’il permet de faire monter en compétence des profils moins matures - ne sera jamais parfait pour vous : permettez à vos équipes de prendre des initiatives et d’innover dans la manière dont elles gèrent leurs difficultés !
