Premiers pas en tant que Scrum Master

Est-ce que je suis à la hauteur ?

Cette phrase résonne en moi depuis cette formation agile de 2 jours, sur le rôle du Scrum Master. En réponse à la demande du formateur : « Quelles sont les questions que vous-vous posez sur le rôle du Scrum Master ? », l’un des participants répond ces simples mots, disant tout haut ce que beaucoup pensent tout bas, parfois même sans en avoir conscience : « Est-ce que je suis à la hauteur ? ».

Pour situer le contexte, pour ceux qui ne connaîtraient pas l’agilité, Scrum, et donc ce qu’est un Scrum Master, petit résumé.

Scrum, c’est quoi ?

D’après wikipédia :

Les méthodes agiles sont des groupes de pratiques de projets de développement en informatique (conception de logiciel), pouvant s’appliquer à divers types de projets. […] Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes. Elles visent la satisfaction réelle du client en priorité aux termes d’un contrat de développement.

Scrum est un schéma d’organisation de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail permettant de répondre à des problèmes complexes et changeants, tout en livrant de manière productive et créative des produits de la plus grande valeur possible ». Scrum est considéré comme une méthode agile.

Et la définition de mon groupe de travail pendant la formation :

L’agilité est une approche permettant de réduire les risques grâce à l’échange et la transparence avec le client, afin de permettre un ajustement permanent et une relation gagnant-gagnant. Pour cela, l’équipe de développement produit et livre de manière itérative des versions fonctionnelles avec de plus en plus de valeur.

Les rôles dans Scrum

En Scrum, il y a 3 rôles :

• L’équipe de développement, qui détient toutes les compétences pour livrer des versions fonctionnelles (des incréments du produit). Chez nous : ergonomie, design, développement, tests.
• Le ou la Product Owner (PO) qui a la vision client, et qui détermine et priorise les fonctionnalités à implémenter dans une grande liste qu’on appelle le Product Backlog. Toute demande sur le projet doit transiter par le ou la PO.
• Le ou la Scrum Master, qui est garant·e du cadre Scrum en favorisant la compréhension, l’adhésion et la mise en œuvre de la méthode. C’est un·e facilitateur/trice qui protège l’équipe en éliminant les obstacles qu’elle rencontre, et en mettant en place des conditions de travail propices à l’efficacité de l’équipe.

A titre personnel, je suis ergonome dans mon entreprise, et à ce titre, je fais partie de 3 équipes de développement sur 3 projets interconnectés. Je suis également Product Owner d’un des 3 projets. Et avec le départ de notre Scrum Master, je deviens Scrum Master d’une autre des 3 équipes (d’où la formation, financée par mon entreprise). Ouais. J’ai une jolie collection de casquettes.

Les évènements Scrum

En Scrum, l’autre truc vraiment important, c’est les évènements. Il y en a 5, ou plutôt 1 + 4.

Le sprint, ou l’itération, c’est une période de temps fixe (2-4 semaines), à travers laquelle se déroulent les 4 autres évènements, et au bout de laquelle l’équipe délivre un incrément du produit, potentiellement livrable. Un nouveau sprint démarre dès la fin du précédent.

Chaque sprint commence par un sprint planning : le ou la PO a préalablement ordonné les items du Product Backlog comme bon lui semble, mais en gros de ce qui a le plus de valeur à ce qui en a le moins. Au sprint planning, on s’assoit tous ensemble et l’équipe décide combien d’items du Product Backlog (combien de fonctionnalités en gros) elle pense être capable de réaliser pendant la durée du sprint. En essayant de tenir compte du fait que « mettre en place une identification sécurisé » ne va pas prendre le même nombre d’heures de développement que « régler le bug du saucisson » (encore que le bug du saucisson a tendance à générer des envies de meurtres de chatons chez nos meilleurs développeurs, mais c’est une autre histoire). Cette liste d’éléments qu’on pense réalisables s’appelle le sprint backlog. Une fois le sprint planning effectué, la liste des fonctionnalités à développer dans le sprint ne doit pas changer : si une demande arrive au cours du sprint, elle sera priorisée par le ou la PO et éventuellement traitée lors du sprint suivant. En cas d’extrême urgence, seul·e le ou la PO peut décider de modifier le sprint courant.

Ensuite, chaque jour, il y a le daily Scrum, point rapide de 15 minutes maximum où chaque membre de l’équipe de développement met les autres au courant de où il en est, ce qu’il compte faire maintenant, et les problèmes qu’il rencontre (dans le but de trouver des solutions, évidemment).

En fin de sprint, il y a le sprint review, où, comme son nom l’indique, on examine le sprint, ou plutôt l’incrément (ce qui a été réalisé). Chez nous, c’est surtout une démo de ce qui a été fait, mais normalement c’est un peu plus large : présentation de ce qui avait été décidé au sprint planning, explication des difficultés, mise à jour du Product Backlog en fonction de ce qui a été réalisé (fini), discussion avec les parties prenantes de l’état courant du projet (budget, financement, conditions du marché), ajustement des éléments du Product Backlog selon les opportunités découvertes…

Enfin, on termine par une rétrospective, dans laquelle on inspecte l’équipe dans un objectif d’amélioration continue : comment le sprint s’est passé ? Qu’est ce qui était bien ? Qu’est-ce qu’on doit améliorer ? Comment ? L’idée est de sortir de là avec des actions concrètes à mettre en œuvre, qu’on ajoute d’office au prochain Sprint Backlog.

La philosophie Scrum

Il faudrait des pages pour développer, mais en quelques mots, Scrum s’appuie sur les principes fondamentaux suivants :

• l’empirisme : transparence (chacun, y compris le client, sait où on en est et où on va), inspection (de l’équipe, de l’incrément) et adaptation (en fonction de l’incrément)
• une équipe auto-organisée et une responsabilité collective
• des valeurs : courage, respect, ouverture, engagement, concentration, confiance
  

On pourrait en dire beaucoup plus, mais il y a déjà genre un million de ressources sur le sujet et je crois que ça suffit pour comprendre le reste. Pour aller plus loin si ça vous intéresse, je vous recommande de lire le Scrum guide et le retour d’expérience Scrum and XP from the Trenches.

Mon expérience

Dans cet environnement de travail, chaque rôle est fondamental. Le rôle de Scrum Master, notamment, est crucial lorsque des obstacles se lèvent sur le chemin de course qu’est le sprint.

J’ai pris mes fonctions de Scrum Master il y a presque deux semaines, en animant la rétrospective de fin de sprint. Après trente minutes à soulever les problèmes actuels et à les évaluer, le problème le plus limitant a semblé être celui de la complexité du code. Certains étaient légèrement septiques sur le fait de pouvoir réellement trouver une solution à ce problème, mais pleine d’enthousiasme et d’optimisme quant à mes nouvelles attributions, j’ai poussé un peu pour qu’on traite le plus gros de leur problème, pensant sincèrement qu’une solution pourrait être trouvée (alors que, soyons honnête, la complexité du code fait parti des nombreuses problématiques liées au développement au sujet desquelles je n’ai strictement aucune compétence). Une heure plus tard, après avoir envisagé plusieurs solutions dont aucune ne semblait vraiment convaincre plus d’une ou deux personnes à la fois, l’équipe finit par décider de faire une journée de travail sur le sujet, afin que tous aient la même connaissance de l’architecture du code en sortant de là. Cette journée fut baptisée la [voix caverneuse] COMPLEXITY DAY.

D’un [voix caverneuse] COMPLEXITY DAY, nous sommes très vite passés à des [voix caverneuse] COMPLEXITY DAYs. En effet, à la fin de la première journée, le code était tout cassé et il restait beaucoup de boulot pour terminer de tout rebrancher avec la nouvelle architecture, d’où la nécessité d’un 2ème [voix caverneuse] COMPLEXITY DAY. Idem à la fin de la 2ème journée, d’où la nécessité d’un 3ème [voix caverneuse] COMPLEXITY DAY. A ce moment là, je ne vous cache pas que je n’en menais pas large, prenant des nouvelles 2 à 3 fois par jour, chaque fois que je croisais l’un ou l’autre des développeurs, et priant secrètement le dieu du développement web pour que ces [voix caverneuse] COMPLEXITY DAYs soient très très très bénéfiques à l’équipe, sans quoi je pourrais être fière d’avoir été la personne ayant animé la rétrospective menant à la pire décision de toute l’histoire de l’équipe.

J’en étais à peu près là, fatiguée et malade par dessus le marché, prête à partir en week-end, quand BigBoss est arrivé à mon bureau pour me demander de faire rebrancher une fonctionnalité qui était présente avant selon lui, mais plus maintenant, et dont il avait besoin genre tout de suite, donc ça pourrait attendre lundi dans la journée mais pas plus, et il ne sera pas là mais faudra lui envoyer par mail. Pour moi, cette fonction n’a jamais été développée, mais il est tellement sûr de lui, avec témoignage d’un autre développeur (externe à l’équipe) à l’appui, que je commence à douter. Si c’est vraiment juste un truc à rebrancher sur la dernière version fonctionnelle (n’oublions pas que la version de développement a des airs de feuilleton post-apocalyptique en ce moment), ça ne devrait pas être bien long, je note dans mon cahier pour y penser lundi matin et en parler avec la PO, absente ce jour là. Mais je doute. Je doute tellement, que, manteau sur le dos et sac à main au bras, je passe la tête par la porte de la [voix caverneuse] COMPLEXITY ROOM pour demander à l’équipe en plein boulot ce qu’il en est : “cette fonction n’a jamais existé, la donnée dont on a besoin n’est même pas dans le schéma de data” qu’on me répond. Perplexe, je retourne voir BigBoss pour lui transmettre l’info, et lui expliquer que par conséquent, ça ne se fera pas en claquant des doigts, ajoutant par dessus le marché que l’équipe a déjà pris du retard par rapport à ce qui a été prévu en sprint planning, et donc que s’il leur rajoute encore du taff ça va vraiment pas être gérable, et que des trucs seront pas livrés en fin de sprint. BigBoss s’agace : “Mais comment ça se fait que c’est pas dans la data ? Ça devrait être dans la data depuis des mois !”. Je lui avoue que je n’ai clairement pas la connaissance pour répondre à cette question, et là… là…
Là, glissade sur la peau de banane, dérapage, erreur de débutante. Je lui dis d’aller voir les devs, ils sauront mieux répondre que moi. Et qu’il me tienne au courant par mail, car j’ai la crève et je rentre chez moi.

WARNING – WARNING – WARNING

Alors qu’est-ce que j’aurais dû faire ? Car tant qu’à se vautrer, autant essayer d’en tirer une leçon… Une idée ? Les suggestions en commentaires sont les bienvenues, j’ai beaucoup à apprendre.

Voici mes idées, après réflexion :
J’aurais pu appeler la PO déjà. Absente des locaux certes, mais elle aurait peut-être répondu, et pu prendre la décision de modifier le sprint pour accéder à la requête de BigBoss, ou raisonner celui-ci sur son besoin absolu qui n’en était peut-être pas un.
Sinon, j’aurais dû simplement lui dire que je verrais ça avec la PO lundi matin, qu’on ferait au mieux étant données nos contraintes et qu’on le tiendrait informé. Et éventuellement, lui rappeler que je n’avais pas l’autorité pour demander à l’équipe de modifier leurs priorités.
En fait, j’aurais pu dire à peu près n’importe quoi, tant que je n’engageais pas l’équipe sur quelque chose qui n’était pas prévu dans le sprint, et que je ne lui disais pas d’aller traiter directement avec eux !

Le pire dans tout ça, c’est qu’il m’a fallu entendre le rapport des développeurs en daily Scrum le lundi matin pour réaliser que j’avais trahi mon rôle de Scrum Master. Au lieu de protéger l’équipe, j’ai donné l’autorisation au loup d’entrer dans la bergerie. J’ai renié toutes mes responsabilités de facilitatrice, protectrice et compagnie pour rentrer chez moi tranquilou-bilou en week-end, et sans même m’en rendre compte. Léger sentiment d’être la pire Scrum Master de tout l’univers…

Est-ce que je suis à la hauteur ? Cette phrase résonne en moi depuis cette formation agile de 2 jours, sur le rôle du Scrum Master. Cette phrase a résonné extrêmement fort ce jour là.

Pardon l’équipe, pardon, et promis, demain je ferai mieux.