À quoi servent vraiment les réunions Scrum ?

«avec Scrum, y a trop de réunions»

Est-ce que comme moi vous entendez cette phrase régulièrement ? Est-ce qu’il y a trop de réunion ?

OU

s’agirait-il de rendre celles-ci utiles, intéressantes, productives ?

Soyons honnêtes je n’ai rencontré personne qui voulait supprimer une réunion qui apporte des résultats.

Posons-nous la question du bénéfice : qu’apportent les cérémonies Scrum ?

C’est même sain de prendre du recul sur les pratiques mises en place afin de vérifier qu’elles soient adaptées. C’est ce que font régulièrement les auteurs du guide Scrum qui ajustent son contenu régulièrement en cherchant à rendre le guide moins prescriptif et à revenir à une version plus minimal.

Alors peut être qu’on ne perçoit pas le bénéfice ?

Scrum est un système avec des règles du jeu (son petit nom était, à l’origine «the new new product developpement game» )

Faire du Scrum c’est donc jouer et respecter ces règles du jeu qui ont été déterminées pour faire en sorte de pouvoir gérer l’incertitude du développement logiciel, favoriser l’apprentissage et l’adaptation en cours de route.

Ces règles se basent toutes sur 3 pilliers que sont l’inspection, l’adaptation et la transparence.

Et c’est précisément ce qui n’est pas toujours compris. Par manque de temps, par facilité, ou pour d’autres raisons les membres des équipes râlent sur l’existance de ces régles du jeu sans en mesurer l’importance ni l’impact sur leur organisation de travail.

Cet article propose d’expliquer le résultat recherché par chaque réunion/cérémonie/évènement que l’on retrouve dans Scrum et le lien que je vois avec les 3 pilliers cités précédemment.

Sprint

Le plus emblématique et paradoxalement celui que l’on remarque le moins est le sprint en lui même. Il s’agit en réalité d’une meta cérémonie compte tenu de sa longueur et qui regroupe toutes les autres.

Une choses difficile à faire pour les humains est de planifier à long terme : on est nul à ça. On ne sait pas jauger le temps qu’il nous faudra pour terminer un travail.

Prenons l’exemple de la lecture d’un livre, allez chercher n’importe quel livre qui se trouve dans votre bibliothèque. Maintenant essayez d’estimer le temps qu’il vous faut pour lire un chapitre, une page, une ligne. Vous allez constater que votre estimation est plus juste pour une ligne, et de moins en moins juste a mesure que la taille de l’object à estimer est important.

Sans compter que plus l’horizon temporel est lointain, plus les hypothèses que nous faisons sont confrontées aux aléas de la vie.

Sachant cela, comment nous contraindre à réduire l’horizon de nos objectifs pour que nos estimations soient réalistes et réalisables dans un temps acceptable ? En utilisant le timeboxing.

Vous connaissez peut-être la méthode Pomodoro qui consiste à appliquer une contrainte de temps de 25 minutes pour chaque tâche à réaliser afin de garantir la concentration et l’atteinte d’objectifs.

Scrum est finalement un gros Pomodoro de quelques semaines au cours duquel une équipe cherche à réaliser un objectif qui devient réaliste et réalisable. Cette pratique donne également l’occasion d’actualiser régulièrement les hypothèses, de prendre du recul avant de relancer une nouvelle timebox.

Par cette pratique nous mettons en oeuvre les pilliers de la transparence et de l’adaptation.

Sprint Planning

Les personnes qui savent le mieux ce qui est possible de faire et comment le faire sont ceux qui vont s’en occuper concrètement. Cela parait une évidence mais l’est-ce vraiment ?

Avez-vous au quotidien la liberté de définir comment vous allez vous occuper de cette nouvelle demande qui est faite à votre équipe ? Et dans tout le paquet de choses qui sont demandées, qu’est-ce qui est vraiment important et qu’il faut terminer en priorité ? Comment choisir ?

Les activités de tri et de prise de décision collective sur ce qui doit être fait en priorité et sur ce qui est réalisable dans un temps donné sont ce qui se passe pendant le sprint planning.

Par cette évènement, nous mettons en oeuvre la transparence dans la priorisation des demandes, dans le choix collaboratif du travail à faire qui participe à un objectif commun.

Ce travail est fait régulièrement ce qui donne l’opportunité de changer les priorités, de pivoter, de corriger, cela grâce au pillier de l’inspection.

Daily Meeting

Le guide Scrum explique que le daily meeting a pour objectif d’inspecter la progression de l’équipe vers l’objectif du sprint et éventuellement adapter le contenu du sprint et en conséquence le travail à réaliser.

C’est tout.

Est-ce qu’il faut que chaque membre de l’équipe réponde aux questions “ qu’est-ce que j’ai fait la veille, qu’est ce que je compte faire aujourd’hui et ai-je des problèmes bloquants “ ?

Non. Et ce n’est pas non plus un point de reporting.

La manière dont se déroule cette réunion est libre mais contrainte en temps (encore une timebox). Il existe certains formats type pour aider les équipes à comprendre le sens de ce moment par la pratique mais vous êtes libres d’inventer la vôtre si vous obtenez le même résultat à la fin : transparence du plan de l’équipe, inspection régulière du plan et adaptation si nécessaire pour garantir l’objectif du sprint.

Sprint Review

En 1950, Norbert Wiener travaille sur un système de pointage automatique des canons anti-aériens et sur la conception des automates.

Par ces travaux, il met en avant le concept de feedback ou de rétroaction : pour contrôler et corriger les actions dirigées vers un objectif précis, la circulation de l’information doit former une boucle fermée permettant d’évaluer les effets des actions déjà entreprises et d’adapter celles qui étaient prévues dans le futur grâce aux informations du passé.

C’est cette notion qui est reprise dans quasi tous les concepts de Scrum et en particulier lors de la Sprint Review : Comment savoir si le produit ou le service que nous développons correspond réellement aux attentes de nos utilisateurs si on ne leur montre qu’à la fin ?

Sur le même rythme que les autres réunion Scrum, la Sprint Review invite l’équipe a partager le résultat de ses réalisations avec ses parties prenantes et ses clients pour avoir l’opportunité d’obtenir des informations permettant de valider des hypothèses, confirmer des besoins, corriger des incompréhensions, etc.

Cette réunion impose la transparence sur le résultat de l’équipe et son inspection pour permettre son adaptation le plus rapidement possible.

Retrospective

L’entropie est une grandeur physique qui caractérise le degré de désordre d’un système. Cette entropie augmente de façon irréversible naturellement.

Cela signifie que plus le temps passe, plus il y a de désordre dans une organisation donnée et moins cette organisation est efficace.

Que peut-on faire pour contrer cette entropie ? Observer ce qui ne marche plus bien et corriger régulièrement.

Ce qui est proposé par Scrum est un moment collectif où chaque membre de l’équipe apporte des éléments qui ne semble plus fonctionner correctement et où tous les membres peuvent proposer des actions pour corriger.

Ce moment collectif est régulier pour garder sous tension l’entropie de l’organisation. Par cette pratique nous mettons en oeuvre les pilliers de la transparence, de l’inspection et de l’adaptation.

J’aime aussi appeler ça de la réparation régulière ou du refactoring d’organisation.

Et après il est possible qu’il y aie réellement trop de réunions.

Si après tout cela vous trouvez que vous avez encore trop de réunions, je vous invite à challenger l’objectif de ces réunions :

• quel résultat est attendu à la fin de cette réunion ?  la production d’un document ? la prise de décisions ? la production d’un plan d’actions ?  
• Est-ce que les personnes qui sont invitées sont les bonnes pour ce qui est attendu ?
• Est-ce que la durée pour cette réunion est la bonne ?
• Est-ce que le format de la réunion est la bonne ? 

S’il s’agit d’atelier qui paraissent inefficaces, j’aime bien rechallenger en utilisant le canvas 7P :

• Purpose : Quel est l’objectif de cet atelier ?
• People : Quels sont les personnes qui doivent participer ?
• Product : Quel est le résultat attendu de cet atelier ?
• Process : Comment concrètement va se dérouler cet atelier ?
• Preparation : Que dois-je préparer en amont pour que cet atelier se passe dans les meilleurs conditions ?
• Practical : Quels sont les besoins logistiques le jour j ?
• Pitfalls : Est-ce que je vois des risques et comment je peux les gérer ?

Et enfin une autre façon de redesign les réunions que j’aime beaucoup est de s’inspirer d’autres formats comme ceux qui sont proposés par les liberating structures.

Pour terminer

Scrum est une boite à outil organisationnelle qui donne une recette toute faite pour bien construire un service ou un produit, limiter l’incertitude et adapter régulièrement le mode de fonctionnement.

Si vous êtes à l’aise à remettre en cause cette boite à outils et prendre vos responsabilités avec ce qui en résultera : adaptez, modifiez, supprimez pour que cela corresponde aux objectifs et aux résultats que l’on attends de vous, mais par pitié ne vous contentez pas de dire «il y a trop de réunions en Scrum».