Les rôles au sein d’une Scrum Team

Cet article vous présentera les rôles au sein d’une équipe Scrum, basé sur ma vision et mes expériences professionnelles.
Pour rappel Scrum est une méthode agile dédiée à la « conduite de projet ». Cette méthode de gestion, ou plutôt ce Framework de management de projet, a pour objectif d’améliorer la productivité d’une équipe en délivrant de manière itérative et incrémentale.
Il existe trois rôles distincts au sein d’une équipe Scrum, Le Scrum Master, La dev team et le Product Owner.

Le Scrum Master

Le Scrum Master est garant de l’application de la méthodologie Scrum au sein d’une équipe. Il doit s’adapter aux problématiques de chaque projet et de chaque équipe dans lesquelles il est amené à intervenir. Son rôle n’est pas d’appliquer bêtement l’ensemble des règles mais de proposer l’implémentation d’artefacts agile adaptés à l’équipe.
Scrum n’est pas une loi de l’agilité mais un « Framework » (un genre de boite à outils), et le Scrum Master est la personne qui à pour rôle de choisir quels outils sont nécessaire pour aider l’équipe pour être plus productive.

Il est aussi la en tant que facilitateur de l’équipe, c’est-à-dire qu’il a ce rôle très important de faire son possible pour éliminer l’ensemble des obstacles rencontrés par l’équipe ; s’il ne peut pas supprimer l’obstacle lui-même, il fera son possible pour trouver ceux qui peuvent le faire et suivre l’avancée.

Néanmoins, il doit faire tout son possible pour rendre l’équipe autonome et ne pas créer de « Scrum Master dépendance ».

Il n’est pas rare de voir qu’un des rôles du Scrum Master est « d’animer les cérémonies ». Je ne suis pas d’accord avec cette affirmation du fait que l’équipe doit être la plus autonome possible (même si cela requiert un certain temps avant d’être atteint). Par exemple, le rôle du scrum master au sens du « scrum guide » est simplement de s’assurer que le daily meeting a lieu et qu’il ne dure pas plus de 15 min. Ou encore lors de la démo, il n’a pas la capacité de présenter le réalisé du sprint, contrairement au Product Owner.

Le Scrum Master est aussi un formateur, bien que cela soit compliqué lorsque le Scrum Master est junior, il doit cependant devenir le formateur de l’équipe. Il aidera le Product Owner à devenir meilleur dans son rôle et aux développeurs à bien comprendre ce qu’est être un développeur agile.

Le Scrum Master n’hésitera pas à faire des ateliers et des formations pour que l’équipe monte en compétence dans le domaine de l’agilité ; il pourra également accompagner les nouveaux membres qui arrivent dans l’équipe afin qu’ils s’adaptent au plus vite. Il ne doit pas hésiter également à sensibiliser les acteurs extérieurs qui ont des impacts sur l’équipe Scrum ; les sensibiliser diminuera le risque que ceux-ci deviennent des obstacles à l’avenir.

Le Product Owner

Le Product Owner est le lien entre le client et l’équipe. C’est donc lui qui, au sein de cette dernière, porte la vision du produit. Il est l’interlocuteur privilégié des utilisateurs. Il devra être très disponible, aussi bien pour les utilisateurs que pour l’équipe. Ses compétences ne se limitent toutefois pas au domaine métier puisqu’il participe activement au sprint et plus particulièrement à la mise en place des tests. Il favorise également la dynamique de l’équipe en maximisant la valeur de leur travail.

Bien que sa présence permanente auprès de l’équipe ne soit pas indispensable, plus celle-ci est importante, plus cela est bénéfique. Sa disponibilité doit être maximale tout au long du projet.
S’il ne décide pas de l’organisation de l’équipe, il est responsable de l’établissement des Users Stories et de leur priorisation. Il devra réétudier régulièrement la priorisation afin de la faire correspondre au mieux aux attentes du client et à la vélocité de l’équipe, itération après itération.
S’il doit être ouvert au feedback du client comme aux remarques de l’équipe lors des rétrospectives, c’est tout de même à lui qu’appartient la décision finale.

Une des grandes responsabilités du Product Owner est donc la priorisation des Users Stories. C’est également un des sujets les plus abordés par ceux qui débutent à ce poste. Pour définir la priorité de chaque Users Stories, le Product Owner dispose d’un certain nombre d’outils ou plus exactement d’une liste de facteurs à prendre en compte :

  • L’importance de la fonctionnalité pour le client (business value)
  • L’estimation initiale donnée par l’équipe (coût)
  • L’expérience apportée
  • Le facteur de risque

Grâce à ces différents facteurs, le Product Owner pourra fixer une valeur étalon qui permettra le classement des différentes Users Stories par priorité au sein du backlog. Le backlog n’est pas définitif et pourra être modifié selon l’évolution des facteurs.
Par exemple, on peut imaginer que le développement d’une fonctionnalité lors d’un sprint apporte suffisamment d’expérience à l’équipe pour lui permettre de revoir à la baisse l’estimation initiale d’une autre fonctionnalité lors d’une prochaine itération.

Par conséquent, un bon Product Owner se doit de posséder les compétences suivantes :

  • Une bonne connaissance du domaine métier
  • Un bon esprit de synthèse
  • La faculté de définir techniquement un produit
  • Un forte capacité d’écoute
  • La capacité de prendre des décisions et de les assumer

Il n’est pas forcément aisé de trouver dans son équipe quelqu’un regroupant toutes ces qualités et faire appel à un coach ou à une formation est souvent nécessaire. Il n’est pas rare de voir des Business analysts se tourner vers le rôle de Product Owner.

La dev team

Souvent appelé « dev team », cette équipe est composée des personnes nécessaires à la réalisation d’un incrément potentiellement livrable. L’appellation « dev team » est réductrice car elle est bien plus qu’une simple équipe composée de développeurs.
En effet, l’équipe doit être complètement autonome sur les différentes tâches d’un incrément et par conséquent doit être composé de toute l’expertise nécessaire à la réalisation de celui-ci. Si une équipe à besoin d’un testeur ou d’un designer, elle doit en intégrer un. C’est pourquoi le scrum guide préconise une équipe composée de 3 à 9 personnes au maximum. 

Cette équipe possède les caractéristiques suivantes :

  • L’équipe doit être autonome, par conséquent personne n’a la capacité de dire comment l’équipe doit réaliser l’incrément.
  • L’équipe doit posséder toutes les compétences nécessaires à la réalisation d’un incrément.
  • Il n’y a pas de hiérarchies au sein de l’équipe
  • Elle ne possède pas de « sous-équipe » selon le domaine d’expertise, tous les membres font parties d’une même équipe quel que soit leurs expertises (développeur, designer, business analyste…).

La taille idéale d’une « dev team » dépend des individus qui la compose. Elle doit être petite pour rester agile mais suffisamment grande pour que les réalisations d’un sprint puissent être significative. En effet, moins de trois membres ne permettent pas une réalisation suffisante au cours d’un sprint sachant qu’elle doit contenir toutes les compétences nécessaires à la réalisation de celui ci. De plus, plus de neuf membres engendre une trop grosse complexité de coordination et engendrera une diminution du rendement de l’équipe.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.