“Et toi tu fais quoi dans la vie ?”

“Scrum Master”

“Ah, euh… c’est quoi ?”

Si vous êtes Scrum Master, et si vous sortez de temps en temps, vous avez forcément été confrontés à ce genre de situation.

Et si vous n’êtes pas Scrum Master, peut-être faites-vous partie des gens qui se demandent ce que fait un Scrum Master. Quels sont ses objectifs, quelle est sa vision de son métier?

Voici ce que je réponds dans les contextes qui nécessitent une réponse très rapide (qui, je le sais, n’est que très partiellement exacte).

“Avant il y avait une certaine façon de gérer les projets dans le monde informatique, appelée le cycle en V, qui posait un certain nombre de problématiques. Aujourd’hui, les entreprises essaient une nouvelle façon de fonctionner, qui les aide entre autre, à délivrer de la valeur plus vite à leur clients. C’est ce qu’on appelle les méthodes agiles. Et comme c’est un changement de cadre radical, ils ont besoin d’accompagner leurs équipes avec quelqu’un qui maîtrise cet environnement de travail. Le Scrum Master est cette personne.”

Le but de cet article est de vous faire une présentation beaucoup plus complète que ce paragraphe.

Je suis Scrum Master depuis bientôt 5 ans, j’ai travaillé avec plusieurs équipes, dans différents contextes, et je vais vous livrer ce qui est à l’heure actuelle ma vision de ce métier qui est le mien. Et même si je vais tenter d’être le plus objectif possible, cela ne reste qu’une vision parmi d’autres.

Le SM, le garant de la pratique agile

Si vous travaillez autour d’un Scrum Master, vous avez certainement entendu ce genre de choses :

“Le SM, c’est la personne qui veille à ce que le timebox des réunions soit respecté”

“Le SM, c’est la personne qui nous force à faire des rétrospectives”

“Le SM, c’est la personne qui arrive à faire avancer le service juridique quand plus personne n’y croit”.

Il y a du vrai dans chacune de ces phrases. Mais prenons de la hauteur.

Car on ne va pas se mentir, Le rôle du SM est souvent un rôle mal compris de l’entreprise.

D’après le Scrum Guide, le rôle du SM se déploie autour de 2 grands axes :

• Le Scrum Master est chargé de promouvoir et supporter Scrum (théorie, pratiques et valeurs).
• Le Scrum Master est un servant-leader de l'équipe Scrum.

Alors oui, on a tout dit et rien dit. Creusons.

Pour illustrer ces axes, j’aime bien utiliser l’image de l’iceberg. Et comme c’est moi qui décide, voici l’image…

On dit que l’agilité, c’est 10% de pratiques et 90% d’état d’esprit.

La pratique, c’est la mise en place et l’explication des rituels (Sprint planning, daily, Sprint review, rétrospective, definition of done, definition of ready (...)). C’est vérifier leur bon déroulement.

La pratique, c’est aussi varier les types de rétrospective, tant dans leur déroulé que leur finalité, c’est remettre en permanence en question la façon de faire les daily, les reviews. La pratique passe également par la mise en place et le maintien du management visuel, c’est trouver les meilleures méthodes de gestion du backlog...

Fort de cette description, de ces éléments, il pourrait être aisé de conclure que le rôle de SM ne nécessite pas un temps plein.

Et pour cause. Cela ne représente qu’une toute petite partie du travail du SM.

Le SM, le catalyseur de “l’esprit agile”

Scrum est un framework agile (une sorte de recette de cuisine, pour simplifier). Et l’agilité, ce n’est pas que des cérémonies.

L’agilité, c’est aussi se soucier de la qualité technique, la qualité fonctionnelle du produit, et tout ce que ça implique. (Vous pouvez lire cet article qui parle entre autres de la qualité technique).

C’est également placer la valeur produit au centre de la démarche et l’amélioration continue, à tous les niveaux.

C’est aussi, mettre en place, ou maintenir une dynamique d’équipe :

• pluridisciplinaire : il n’y a pas que des développeurs dans l’équipe Scrum. Idéalement, on y trouve aussi des acteurs de l’UX, QA, éventuellement marketing.
• autonome : une équipe doit être en mesure de réaliser en autonomie l’engagement pris en sprint planning.
• collaborative : une équipe, ce n’est pas qu’une somme d’individus. C’est la collaboration des membres d’une équipe qui forment sa dynamique.

L’agilité, c’est reconnaître le rôle du PO en tant que véritable responsable et décisionnaire du produit et l’aider à récupérer les feedbacks clients.

L’agilité, c’est encore beaucoup de choses, mais je pense que vous voyez où je veux en venir...

Alors, oui, vous allez me dire “la qualité du code, c’est le devoir de tout bon développeur”, “récupérer les feedback utilisateurs, c’est le rôle du PO”, “l’amélioration continue on peut très bien travailler dessus sans Scrum Master”.

Le Scrum Master n’a pas pour vocation de mettre en place une intégration continue, un SonarQube, ou récupérer les feedback clients. Il n’est pas question de faire le travail des autres. En revanche, il doit être le catalyseur de ces démarches.

C’est lui qui doit expliquer au groupe (et parfois aux développeurs eux-mêmes) qu’une erreur n’est pas un échec. C’est parce qu’on a le droit à l’erreur dans l’organisation, qu’on va se permettre d’essayer, d’être audacieux, de sortir des sentier battus, et donc, grandir.

C’est lui qui doit inviter les membres de l’équipe à prendre du recul sur leur travail, sur celui des autres, pour leur permettre le fameux “Inspect and adapt”.

Il doit inviter l’équipe à se poser des questions. “Comment peut-on apporter plus de valeur à nos tests ?” “Est-ce qu’on est plus efficace en télétravail ? Pourquoi ?” “Qu’est-ce qui fait qu’on est meilleur le mardi et moins bon le vendredi ?”, “Et d’ailleurs, ça veut dire quoi pour nous, être meilleur ?” “Est-ce que notre process de MEP est optimal ?” “Est-ce qu’un nouvel arrivant est bien accueilli ?”.”Est-ce que le sujet intéresse toujours les développeurs ?” “Est-ce que les membres de l’équipe ont du temps pour se former ?” etc etc…

Notons bien que les réponses viendront de l’équipe dans sa globalité. Ce n’est pas son rôle de répondre à tout ça. Si l‘équipe manque d’autonomie, il peut au mieux orienter et faire des préconisations.

Si ces questions et la démarche vous semblent triviales, c’est bon signe, c’est que vous êtes déjà auto-organisé. Ça tombe bien c’est aussi un des devoirs du Scrum Master.

Le Scrum Master se positionne donc en “servant-leader” de l’équipe, non pas en lui faisant le café, ou en réservant les salles de réunion, comme j’ai pu l’entendre parfois, mais bien en l’interrogeant sur ses méthodes de travail, et en l’aidant à les optimiser/améliorer. Il joue également un rôle important en tant qu’agent de changement plus largement dans l’organisation.

Et parfois, ok, il fait le meilleur café du monde...

Le SHU HA RI (se prononce chou ha li)

Non, alors, pas du tout.

Le Shu Ha Ri, c’est un terme japonais, emprunté par les agilistes, qui décrit le processus d’apprentissage des arts martiaux jusqu’à leur maîtrise.

On l’utilise souvent pour parler de la maîtrise du cadre de Scrum d’une équipe, ou d’une entreprise.

Et selon où en est l’équipe dans la maîtrise de ce cadre, il n’est pas demandé la même chose au SM.

Une équipe novice (Shu), va mettre en place et appliquer les règles de Scrum sans pour autant avoir besoin de les comprendre dans leur ensemble, que ce soit en terme d’impact, de philosophie, de dynamique etc... Le Scrum Master va adopter une posture haute, une posture de sensei (sachant). Il va enseigner les théories et pratiques de Scrum. Les fameux 10% dont on parlait plus haut. Son rôle sera essentiellement de la formation et du transfert de connaissance. Cette phase est plus ou moins longue en fonction des équipes. Sur les équipes que j’ai accompagnées, 5 ou 6 itérations était un minimum.

En pratiquant, encore et encore, l’équipe va passer en Ha. L’équipe commence à être autonome sur les pratiques Scrum en tant que telles, et le SM peut se concentrer sur l’état d’esprit agile. Sa posture basse doit permettre à l’équipe de se questionner sur ses pratiques au quotidien, et d’y trouver des améliorations. Au sein de l’équipe, il transmet l’envie de tester, l’envie d’aller vers des pratiques inconnues. Celle-ci ne fait plus les rituels parce qu’il faut les faire, mais bien parce qu’elle comprend le bien fondé de ceux-ci.

Puis, vient le Ri. L’équipe se challenge elle-même. Forte de sa capacité à apprendre, elle sait, en autonomie, adopter de nouvelles façons de faire. Le rôle du SM évolue donc encore peu à peu vers un mentorat. Au sein de l’équipe, il est là pour recadrer les éventuelles dérives, pour apporter une vision neuve, ou de nouvelles pratiques. Il peut alors embrasser pleinement son rôle d’évangélisation au sein de l’organisation. Pourquoi pas mettre en place un framework de synchronisation entre les équipes. Pourquoi pas travailler sur l’acceptation du rôle de PO en tant que décideur à 100% sur son produit. Il peut se concentrer sur la vision entreprise de l’agilité, et prendre de la hauteur par rapport à l’équipe. Il pourra, petit à petit, adopter une posture de coaching plus ponctuelle.

Ici,  je parle de “l’équipe” comme si celle-ci ne variait jamais. Dans la vraie vie, des gens arrivent, partent, l’équipe change, le besoin évolue, et donc, les méthodes aussi. Donc imaginer un voyage linéaire au travers les étapes du SHU HA RI est illusoire. En plus du fait que l’équipe peut être en maîtrise sur un aspect agile, mais débutante sur d’autres.

Conclusion

Il est très difficile de décrire un travail qui change chaque jour, qui est différent d’une organisation à une autre, d’une équipe à l’autre, et d’une personne à l’autre. J’espère avoir tout de même réussi dans cet article à vous donner quelques clés de compréhension des objectifs que je me fixe en tant que Scrum Master.

Mon travail est dans un premier temps un travail d’observation, pour comprendre où en est l’équipe dans son application de l’agilité d’une part, et sur ses process et méthodes de travail au sens large, d’autre part. Une fois cet “audit” fait, place à l’action, en pointant les difficultés observées, et en invitant l’organisation, l’équipe ou les personnes à y réfléchir. Et cela, tout en propageant l’état d’esprit dont je parlais précédemment.

Une dernière chose avant de se quitter, dans cet article, j’aborde la notion de Shu Ha Ri pour illustrer la pluralité du rôle de Scrum Master selon la maturité de l’équipe. Mais la “maturité agile” n’est qu’un des très nombreux facteurs différenciants d’une équipe à l’autre. Une équipe constituée de juniors ne sera pas accompagnée de la même manière qu’une équipe de séniors, ni qu’une équipe “mixte”. Et pour chaque facteur qu’on peut imaginer, un accompagnement spécifique est à trouver.