7 erreurs à ne pas commettre pour un Scrum Master

7erreurs-a-ne-pas-faire-pour-un-scrum-master

Faire du Scrum master un Chef de projet :

La première erreur est de confondre le rôle de Scrum Master à celui de Chef de projet. Ce sont deux métiers bien distincts (voir : Les 6 qualités du Scrum Master). Cependant, même si l’on connaît parfaitement les deux rôles, il arrive souvent que la personne occupant le poste de SCRUM Master soit un ancien Chef de Projet, du coup les habitudes ont tendances à revenir assez rapidement.

Le souci dans ce cas là est que généralement les Chefs de projet ont tendance à organiser les tâches et le travail de chacun au lieu de favoriser l’auto-organisation. Et l’une des valeur fondamentale d’une équipe agile est tout de même de s’auto-organiser.

Pour pallier à ce problème il faut tout d’abord que le Scrum Master prenne conscience de son défaut. Partant de là il faut qu’il arrête de mettre son énergie à déterminer ce qui doit être fait (rôle qui revient en grande partie au Product Owner) mais plutôt qu’il la dépense à aider son équipe à trouver comment le travail peut être fait.

Mélanger le rôle de Product Owner à celui de Scrum Master

Là aussi il s’agit encore d’outrepasser le périmètre du métier de chacun. Il ne faut pas que le Scrum Master se prenne pour le Product Owner, et vice versa. Lors d’un projet réalisé sous la méthode SCRUM, la perte de temps que représente les discussions sur le rôle de chacun peut être très importante et s’avérer ralentir énormément le projet. Ceci est néfaste pour l’ensemble de l’équipe.

Il faut donc encore une fois bien définir les tâches et responsabilités de chacun. Pourquoi pas rédiger une matrice des rôle avec une liste de tâche et leur attribution et l’afficher dans le bureau.

Laisser l’équipe travailler sur trop de fonctionnalités en même temps

Il arrive que l’équipe mette trop de features dans un seul même sprint. En effet les développeurs peuvent ajouter à la volée une ou deux fonctionnalités sans pour autant suivre le workflow et donc l’avancée des features développées par leurs collègues. Le problème ici est que lorsque l’on lance trop de features à developper en même temps il devient très difficile de se concentrer sur une seule et même tâche et ceci va retarder le temps de livraison.

Ici le SCRUM Master doit « surveiller » le workflow et s’assurer qu’il n’y ait pas trop de fonctionnalités développées en même temps. Pour cela il doit être à l’écoute des développeurs et savoir ce que fait chacun. Un story board peut être utile pour s’informer régulièrement sur le workflow et savoir qui fait quoi et où en est chaque membre de l’équipe.

Ne pas coacher l’ensemble de l’organisation

Le rôle du Scrum Master ne consiste pas uniquement à s’occuper de son équipe. Il a un poste clé et doit jouer un rôle important dans la transition digitale de l’ensemble de l’entreprise. Il doit entrainer toute l’organisation vers l’agilité. Il peut se présenter comme leader voire même coach en assurant une aide pour la transition vers l’agilité de l’entreprise. Ses compétences son essentielles à cette évolution vers l’agilité.

Pour ce faire il faut que l’entreprise lui en donne les moyens et cela commence par reconnaître ses compétences en le présentant comme référent et pourquoi pas inciter les divers collaborateurs à aller vers lui pour en savoir plus sur l’agilité. Il peut aussi se faire aider d’un coach agile pour lui apprendre à entrainer une organisation entière vers l’agilité (ce qui n’est pas chose facile !).

Ne pas être l’appui du Product Owner

Tout à l’heure nous disions que le SM devrait coacher l’ensemble de l’organisation. Mais cela concerne aussi le Product Owner. En effet il ne doit pas uniquement se concentrer sur les tâches de l’équipe de développeurs. Il doit être un réel appui au PO et l’aider à construire un produit qui apporte un maximum de valeur. Son rôle est donc de l’initier à la méthode mais aussi l’aider à établir un backlog pertinent.

Ne pas reconnaître la légitimité du Scrum Master

On parle ici du « midle management ». Certains Managers (au dessus hiérarchiquement du Scrum Master) ont tendance à penser qu’il sont les seuls à pouvoir insuffler un état d’esprit agile dans l’organisation. Du coup ils peuvent parfois considérer que le Scrum Master n’est qu’un simple « assistant » et ne joue pas un rôle décisif dans la transition agile. Comme si son pouvoir de « coach » ne s’étendait uniquement au niveau de sa propre équipe. Et c’est tout à fait faux, comme nous l’avons dit plus haut, le Scrum Master doit pouvoir coacher l’ensemble de l’organisation.

Le cas contraire est tout aussi néfaste pour l’entreprise. Si les managers se prennent pas pour les unique « coach agiles », cela peut être encore pire  : Ils peuvent refuser catégoriquement toute tentative de changement, d’utilisation de méthode différente et ne pas vouloir entendre parler du tout de méthodes agiles. Il deviennent alors un vrai frein vers cette transition.

Faire tourner le rôle de SCRUM Master

Ce 7e point est assez controversé. Il existe des équipes Scrum qui considèrent que tous les membres d’une équipe peuvent être Scrum Master. Elles changent alors son rôle régulièrement. Les responsabilités du Scrum Master tournent donc et passe d’un collaborateur à un autre dans la même team. Ils défendent cette idée en expliquant que le but principal d’un Scrum Master est d’avoir une équipe tellement performante dans la méthode qu’il en devienne inutile.

Seulement si c’est le cas cela doit tout d’abord vouloir dire que la team est arrivé à un niveau de maitrise de la méthode extrêmement élevé. Et même si cela arrive ça signifierait que le Scrum Master peut effectivement les laisser continuer seuls, mais en aucun cas cela signifie que le rôle peut tourner d’un membre à un autre.

Source : Luis Gonçalves

2 réflexions au sujet de « 7 erreurs à ne pas commettre pour un Scrum Master »

  1. Bonjour,

    Je ne comprends pas l’argumentaire utilisé au point 7) « Faire tourner le rôle de SCRUM Master ». Quelle est la raison invoquée pour ne pas faire tourner le role de SCRUM Master ?

    Cordialement,
    Jean-François

    • Bonjour Jean-François

      L’argument avancé contre le changement du rôle de Scrum Master par Luis Gonçalves est qu’à chaque fois qu’un rôle est changé au sein de l’équipe les différentes interactions entre chacun des membres changent. Il faut prendre en considération le temps que cela prend et les différentes étapes pour construire une vraie team et changer ce rôle peut obliger l’équipe à recommencer le processus depuis le début.
      Encore une fois ce point ne met pas d’accord tout le monde, certaines teams défendent cette méthode et d’autres pas du tout.
      J’espère avoir éclairé un peu plus sur ce point, si ce n’est pas le cas n’hésitez pas à reposer votre question.

Laisser un commentaire

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