De développeur à Scrum Master : 5 clés pour bien démarrer

Avec la propagation des méthodes agiles, il est fréquent que des développeurs soient désignés Scrum Master. Code, architecture, configuration : on apprend en permanence, pas de problème. Mais pour un rôle dont l’essence n’est absolument pas technique, l’apprentissage est plus difficile.

Après un ou deux projets agiles, on pense connaître la méthode, on va simplement reproduire ce qu’on a vu faire. Et puis arrivé de l’autre côté du miroir, on s’aperçoit qu’on en maîtrise pas tant que ça les ressorts, qu’il nous manque des détails, que face à des aspects spécifiques du projet on ne sait pas quelle réponse donner. Et bien sûr, vos coéquipiers, voir vos supérieurs, comptent sur vous. La pression.

Développeur devenant Scrum Master pour la première fois, cet article est pour toi : quelques recommandations pour acquérir un maximum de confiance au démarrage. Je me focalise sur l’animation des réunions et de la rétrospective, mais les principes de fond s’appliquent à l’ensemble de ton action dans le projet.

Tout d’abord, on se rassure. Des personnes avec des profils et des personnalités différentes sont devenues d’excellents Scrum Master. C’est facile, ça s’apprend, c’est juste un peu déroutant au début.

1) Préparer et dé-préparer les rituels

Les rituels sont déjà posés dans le calendrier de l’équipe : planning d’itération ; démonstration + rétrospective ; stand-up meeting. Mais pour le Scrum Master, un temps de préparation est nécessaire afin de ne pas arriver à la course :

• préparation mentale : 10 minutes.
  Réviser le déroulement de la réunion, récapitule les ateliers, répète les introductions que tu feras. Réfléchit aux problèmes délicats qui pourraient être abordés : tu devras garder de l’énergie pour rester au dessus de la mêlée dans ces moments là.
• logistique : 15 minutes.
  Vérifie et règle les points techniques (salle, projecteur, réseau, post-its, marqueurs, etc)

Le meilleur moyen de toujours se préparer, c’est d’inscrire cette préparation dans son calendrier plutôt que dans sa tête : un rendez-vous de 25 minutes avant les rituels, avec répétition automatique à chaque itération.
À présent, quand les participants arriveront en réunion, ils te trouverons déjà là, bien en confiance. Et si tu te fais confiance, ils te feront confiance.
Puisqu’on parle de calendrier, du temps en sortie de réunion doit être réservé :

• mise en oeuvre des décisions : 1H, dans la demi-journée suivant la réunion.
  Si des décisions concernant le backlog ou le tableau de bord de l’équipe ont été prises, le plus simple sera de les mettre en oeuvre dans la foulée. Donc idem : calendrier, rendez-vous de 1H, répétition à chaque itération.
• décompression : 1H à 2H après la rétrospective.
  Le rôle de facilitateur est hors de ta zone de confort, tu fatigueras vite. Rester au dessus de la mêlée, ne pas se laisser entraîner dans les émotions du groupe, ça prend de l’énergie. Beaucoup d’énergie. Donc évite les tâches compliquées dans la foulée, tu n’auras peut-être pas l’énergie pour les réaliser. Préserve-toi, l’équipe a besoin de toi.

Au bout du compte, le rôle de Scrum Master devrait prendre environ 20% de ton temps. Lors des 80% restants, tu seras un développeur comme les autres. C’est un rôle, pas un poste à plein temps.

2) Se focaliser sur le cadre des rétrospectives

L’animation des rétrospectives est la partie qui m’impressionnais le plus quand j’ai débuté comme SM. Plus que l’animation elle même, c’est de veiller au bon déroulement qui était stressant : que les participants restent dans les temps, évitent les digressions, s’assurer qu’ils ne se coupent pas la parole, etc.

En introduction de réunion, il est essentiel de poser Le Cadre : un accord passé entre les participants pour tirer le meilleur parti du temps passé ensemble. Introduis la séance en rappelant ce cadre :

• le but de la réunion (vérifie s’il y a d’autres attentes si tu as un doute)
• le temps prévu (demande si certains ont des contraintes de temps)
• les participants et leurs rôles, si c’est la première fois ou que des nouveaux participent
• le déroulement prévu, et le découpage du temps que tu proposes (vérifie que tout le monde acquiesse)
• les règles éventuelles

A présent, comme chacun connait le cadre, il comprendra tes interventions, et tu pourras t’y référer pour recadrer la réunion. Sans cadre, pas de recadrage possible. Si tu t’aperçois que tes interventions ne sont pas comprises, c’est le plus souvent parce que les participants ne comprennent pas leur justification : fais dans la pédagogie, repars du cadre. Exemples :

• “je vais te demander de conclure rapidement, sinon le tour de table va durer trop longtemps et nous n’aurons pas le temps de discuter les points ensuite”
• “je vous propose d’en parler plus tard, car là c’est la démo, on a dit qu’on vérifiait juste les user stories et qu’on ne ferait pas d’exploration”
• “est-ce que vous êtes toujours dans le sujet de la réunion ?”

Si les participants grognent, renvois la décision sur eux : «souhaitez-vous prendre plus de temps ?», «est-ce que vous voulez qu’on change l’agenda de la réunion ?», «est-ce que vous souhaitez interrompre le tour de table pour parler de XXX ?». Le facilitateur doit veiller au respect du cadre, mais ça n’empêche pas de le changer si tout le monde est d’accord.

N’aies pas peur si tes réunions ont l’air protocolaires les premières fois : tu feras le mariole quand tu seras à l’aise.

3) Ne pas entrer dans les discussions lors des rétrospectives

Pour réussir ses premières facilitations, le secret est de rester en dehors des débats. N’aies qu’un seul objectif : le déroulement de la réunion, pas son contenu. Si ça t’es difficile au départ, un exercice extrême : n’écoute pas les discussions.

Rentrer dans les débats, c’est THE erreur de facilitateur, celle qu’on voit le plus, qu’on a tous fait, que personnellement je refais régulièrement. Il est très difficile et fatiguant de passer d’une position à l’autre, de s’engager dans les discussions puis d’en sortir. Pris dans les échanges, on oublie de gérer la réunion et elle dérape : les autres s’appuyaient sur toi pour veiller au cadre, mais tu étais occupé à participer…

Je sais, parfois ça va être très dur : par exemple, quand tu auras une solution à proposer au problème dont parlent tes coéquipiers. J’insiste : ne propose pas ton idée, ne t’en mêle pas. Laisse leur le contenu, reste sur le cadre. Être facilitateur, c’est comme faire une fête chez soi : on en profite peu, mais ça fait plaisir que les invités s’amusent.

Avantage : en renonçant à participer, ton sens de l’écoute et de l’observation vont se développer instantanément. Tu comprendras des choses sur les rapports dans ton équipe, tu verras beaucoup plus de détails sur les comportements des uns et des autres, et sur la dynamique de la réunion. On pourrait dire que tu verras les discussions en mode DEBUG et plus seulement en mode INFO ou WARN.

4) Assumer sa légitimité

Souvent lorsqu’on débute on hésite sur la position à adopter : faut-il être strict sur les règles, peut-on se montrer directif, etc. On doute d’avoir le pouvoir d’agir, et de la manière de l’utiliser. Le secret : ce pouvoir, ce sont tes coéquipiers qui te l’ont donné. Ils sont d’accord pour que tu agisses. Ils t’ont désigné Scrum Master.
Une fois que tu as saisi cette dynamique, tu peux leur demander de l’aide sans remettre en cause ta légitimité :

• demander ce qu’ils attendent de toi, en réunion ou à l’occasion d’un café avec un collègue. Exemples :
  «Je vois qu’on a débordé de 20 minutes ; la prochaine fois vous voulez que je sois plus strict sur la montre ?»
  «quand vous avez dérapé sur le sujet du bug, vous auriez voulu que je vous coupe ?»
• déléguer certaines tâches ou responsabilités :
  “quelqu’un veut bien noter les décisions ?”,
  “Mathieu, tu fais les rappels de temps ?”,
  “Philippe, tu voudrais maintenir à jour le tableau de bord ?”

Tes coéquipiers t’ont attribué un rôle et des responsabilités mais ils ne t’ont pas laissé seul : n’aies pas peur de leur demander leur aide.

Effet kiss cool : quand on est un peu expérimenté, on peut contredire le conseil 3) “Rester en dehors des discussions” en délégant toute la facilitation à un collègue le temps de la discussion, puis reprendre le lead de la réunion. … Mais pour tes débuts, disons les 3 premières rétrospectives, n’y pense même pas, ne joue pas avec le feu (j’aurais même pas dû en parler…)

5) Echanger avec ses pairs

Un dernier point trop souvent oublié : on comprend souvent mieux la situation et ce qu’on doit faire quand on en parle avec quelqu’un. Echanger avec des personnes hors de ton projet te feras prendre du recul et progresser (d’autres Scrum Master, des coachs agiles, un mentor, etc). D’autres pratiquants n’attendent que toi pour échanger dans une des nombreuses rencontres agile (les franchises ne manquent pas : Agile Tour, Agile France, Scrum Days, FSUG, Agile .Net, etc).

Voilà, ça devrait t’aider à éviter les principaux écueils.

Chaque Scrum Master apporte un peu de son caractère à son équipe. Certains apportent une forte cohésion par leur empathie, d’autres amènent leur passion pour les métriques, certains documentent beaucoup : chacun son style. Tu veux être un bon Scrum Master ? Sois toi-même, fais les choses à ta manière, et développe ton style. Que le post-it soit avec toi.

Tags: Débuter, Facilitation, Getting Things Done, Rétrospective