Les défis d’un Scrum Master selon son expérience passée
Dans ma carrière d’Agiliste, j’ai pu croiser une multitude de Scrum Masters aux bagages très différents. Ce qui est intéressant avec ce métier, c’est qu’il n’est pas enseigné à l’école. Peut-être que les cours en informatique ou en gestion effleurent-ils le sujet un peu, mais la formation de Scrum Master n’est pas obligatoire pour passer la certification. Et si on décide de la suivre, ça prend généralement 2 jours, et on y voit surtout la base du framework Scrum.
Or, être Scrum Master c’est aussi être, comme j’aime l’expliquer, « un spécialiste des êtres humains dans un environnement technologique ». La formation de SM ne couvre que très peu les différents moyens d’assurer une bonne auto-organisation d’équipe, les approches pour engager nos coéquipiers, de s’assurer qu’ils s’approprient leur travail, etc.
Je me lance dans une grossière estimation : Dans 90% cas, les gens qui sont aujourd’hui des Scrum Masters ou Coach Agiles étaient auparavant soit des développeurs, des gestionnaires ou des chargés de projet. Pour certain, ils le sont devenus par choix, et d’autres se sont vu assigné ce rôle suite à une décision d’entreprise. Il n’est pas rare, par exemple, qu’un développeur devienne SM de son équipe car il connaît davantage les processus Scrum. Ou alors qu’un chargé de projet devienne SM « par défaut » suite au passage de l’entreprise à l’approche Agile.
Or, d’où l’on vient dicte parfois où l’on va, et je crois que c’est un peu le cas des agilistes. Notre expérience du passé risque grandement d’influencer notre approche en tant que Scrum Master, et chacun risque de rencontrer des difficultés ou d’appliquer d’anciens réflexes en accompagnant son équipe. Comme en être conscient, c’est 50% du problème de réglé, je me suis dit que ça ne ferait pas de mal d’écrire à ce sujet.
J’ai fait une compilation de ce que je crois être « les qualités d’un bon Scrum Master / Coach Agile ». Je ne prétends pas avoir tout juste, mais l’idée est de voir quelles difficultés risque de rencontrer un Scrum Master en fonction de son « background » professionnel. Pour couvrir une majorité de cas, je vais surtout me concentrer sur ceux qui ont un background en développement logiciel, en gestion d’équipe et en charge de projet. J’y vais assez simplement, avec des listes d’avantages et inconvénients.
Être Scrum Master lorsqu’on a une expérience de développeur
C’est un cas très commun. Il n’est d’ailleurs pas rare qu’un développeur fasse office de Scrum Master à mi-temps. Je m’abstiendrai de me prononcer en profondeur sur cette pratique, ne l’ayant pas essayée, mais disons qu’un SM dédié peut avoir bien assez de travail pour ne pas avoir à coder, tout dépend des attentes de l’entreprise et de l’équipe.
Un ex-développeur aura de la facilité à :
- comprendre le volet technologique du produit, cela lui servira tous les jours
- trouver la balance entre qualité et efficience
- appliquer les concepts de simple-design et de refactoring, qui ne lui seront pas inconnus
- faciliter les processus nécessaires à l’assurance qualité
- appliquer et défendre les pratiques telles que le pair-programming et le peer code review
Un ex-développeur pourrait avoir de la difficulté à :
- gérer les relations interpersonnelles et les conflits s’il n’y est pas habitué
- assurer l’auto-organisation de son équipe si, par exemple, il était chef d’équipe et avait l’habitude de décider « qui fait quoi »
- garder en tête que le principe est plus important que la pratique
- être un agent de changement ou oser perturber l’ordre établi
- savoir laisser son équipe se planter quand nécessaire
- exercer son pouvoir d’influence
- pouvoir faire un suivi du sprint ainsi que des projections
- créer des chartes burn-up et roadmaps
- faciliter les relations avec le client
Être Scrum Master lorsqu’on a une expérience de chargé de projet
Cas typique suite à une gestion de changement dans une entreprise qui est passé du « waterfall » à l’agilité. Pour plus d’un, le chargé de projet peut aussi bien devenir Product Owner que Scrum Master, comme s’il s’agissait d’une pièce du jeu Tetris qui s’emboîte tout seul dans l’équation. J’ai eu de nombreux cas où cela a effectivement bien fonctionné, d’autres moins bien.
Un ex-chargé de projet aura de la facilité à :
- faire le suivi du sprint ainsi que des projections
- créer les chartes burn-up et les roadmaps
- faciliter la relation avec le client
- amener l’équipe à être orienté vers un objectif commun
Un ex-chargé de projet pourrait avoir de la difficulté à :
- gérer les relations interpersonnelles et les conflits s’il n’y est pas habitué
- assurer l’auto-organisation de son équipe et se retenir de déterminer « qui fait quoi »
- garder en tête que le principe est plus important que la pratique
- être un agent de changement ou oser perturber l’ordre établi
- savoir laisser son équipe se planter quand nécessaire
- balancer qualité et efficience
- être au service de l’équipe et non le contraire
- maitriser les concepts de simple design, refactoring, assurance qualité, pair programming
- laisser l’équipe estimer son travail
Être Scrum Master lorsqu’on a une expérience de gestionnaire
Ce cas-ci est beaucoup moins fréquent, et tout dépend aussi de quel genre de gestionnaire il est question. Prenons le cas d’une bonne gestion orientée vers les personnes. Quelqu’un ayant une bonne expérience de gestion d’équipe aura sans doute plus de facilité à saisir la dimension de leader engagé (servant leader).
Un ex-gestionnaire aura de la facilité à :
- gérer les relations interpersonnelles et les conflits
- assurer l’auto-organisation de son équipe et responsabiliser ses coéquipiers
- garder en tête que le principe est plus important que la pratique
- être un agent de changement ou oser perturber l’ordre établi
- savoir laisser son équipe se planter quand nécessaire
- exercer son pouvoir d’influence
- amener l’équipe à être orienté vers un objectif commun
Un ex-gestionnaire pourrait avoir de la difficulté à :
- comprendre le volet technologique du produit
- trouver la balance entre qualité et efficience
- appliquer les concepts de simple-design et de refactoring
- faciliter les processus nécessaires à l’assurance qualité
- appliquer et défendre les pratiques telles que le pair-programming et le peer code review
Au final, peu importe l’évolution de la carrière d’un Scrum Master, il sera amené à maitriser des éléments d’un milieu qui soit lui est étranger, soit qu’il ne maîtrise pas naturellement. Le plus important dans tout cela, est que l’agilité existe pour les gens et non pour les technologies. Sans coéquipiers, pas d’agilité, pas de Scrum, pas de logiciel. Le Scrum Master doit donc garder le cap sur le fait que des humains composent son équipe, et que c’est eux qu’il doit développer en priorité.
Je conclurai avec une citation que j’ai vu passer sur LinkedIn alors que je rédigeais cet article (la traduction est de moi), et qui résume assez bien, je crois, le défi premier de tout agiliste :
Si vous vous retrouvez à vous concentrer sur la technologie plutôt que sur la sociologie, vous êtes comme le personnage de vaudeville ayant perdu ses clés dans une rue sombre, et qui les cherche sur la rue d’à côté parce que, comme il l’explique, « la lumière y est meilleure ».
- Tim Lister and Tom DeMarco, Peopleware
Merci à mon collègue Éric Laramée pour la citation.
Propriétaire de Primos Populi. En tant que gestionnaire, je préconise l’approche “les gens d’abord, et le reste suivra”. Mes sujets de prédilection sont la culture organisationnelle, le droit à l’erreur et l’abaissement du centre de gravité du pouvoir décisionnel. Je cultive l’épanouissement des gens.
Originally published at www.primospopuli.com on March 11, 2017.