Lourdeur des réunions Scrum
Ceci est une traduction libre de l’article « Scrum Myths: Scrum is « Meeting Heavy » » de Barry Overeem – Co-Fondateur de @The Liberators | Professional Scrum Trainer @Scrum.org
Lorsque le cadre méthodologique Scrum est introduit dans une entreprise, la plupart du temps l’équipe de développement l’adopte avec beaucoup d’enthousiasme.
Cette approche agile est appréciée car elle favorise l’émergence d’équipes auto-organisées, autonomes et pluridisciplinaires, en reconnaissant les qualités individuelles et renforçant les forces de l’équipe dans son ensemble.
En effet, est-ce qu’il y a encore des personnes qui ne veulent pas faire partie d’une équipe Scrum ?
« Depuis l’introduction de Scrum, je passe mon temps à assister à des réunions, je ne suis pas devenu développeur pour assister à des réunions toute la journée. » « Avec Scrum, j’espérais que nous aurions une culture d’équipe, mais au contraire, cela ressemble plus à une culture de la réunion. » « Je pensais que les réunions de Scrum étaient rapides et efficaces. Cependant, notre Daily Scrum prend au moins 30 minutes et après, nous n’avons toujours pas d’organisation claire et solide. »
Le Guide Scrum indique que les cérémonies Scrum (à noter : elles ne sont jamais appelées « réunions ») sont utilisées pour créer de la régularité et minimiser le besoin de réunions non définies. Tous ces événements sont contraints dans le temps, de sorte que chaque rituel possède une durée maximale.
Les cadres temporels (ou timebox) suggérés pour un sprint de 1 mois sont :
- Daily Scrum : 15 minutes
- Planification de sprint : 8 heures maximum
- Sprint Review : max 4 heures
- Sprint Rétrospective : max 3 heures
- Amélioration / Revue du Backlog produit : en moyenne 10% de la capacité de l’équipe de développement.
(A noter : ces durées peuvent être aisément réduites de moitié pour des sprints de 2 semaines)
Alors pourquoi ce sentiment de pesanteur récurrent au sein des équipes ?
Cérémonies Scrum dynamiques
Voici les éléments qui me font dire que les équipes ont cette impression :
- La durée des cérémonies Scrum ne sont pas conservées comme elle devrait l’être.
En effet, passer plus de temps que prévu (tel qu’énoncé dans le Guide Scrum) ne devrait pas être nécessaire. Et pourtant, il m’est arrivé d’assister à un daily scrum durant près de 45 minutes … - Les rituels Scrum manquent d’une structure claire.
S’il n’y a pas de structure claire et un agenda bien défini, il est difficile de respecter ce qui a été prévu et d’atteindre le résultat attendu. - L’équipe n’est pas correctement préparée.
Chaque rituel Scrum nécessite une bonne préparation de la part de l’équipe. Pour moi, ce n’est pas seulement une marque de professionnalisme, mais c’est aussi une indication de respect envers les autres membres de votre équipe. - Les réunions non définies dans le cadre Scrum ne sont pas réduites, voire supprimées.
Souvent, l’équipe doit assister à d’autres réunions en plus des cérémonies régulières fixées par la méthode Scrum. Par exemple : les compte-rendu d’avancement à plusieurs niveaux de l’entreprise (COPROJ, COPIL, CODIR, etc.), des présentations diverses et variées, des séances de partage de connaissances ou des rencontres avec un client, …
C’est parfois inévitable mais idéalement cela devrait être limité autant que possible. - Les réunions ne sont pas adaptées à l’emploi du temps d’un développeur.
Pour la plupart des managers et des chefs de projet, le fait d’assister à des réunions toute la journée est une partie intégrante de leur activité. Ils sont employés pour aller d’une réunion à l’autre. Pour un développeur, c’est différent. Faire de la programmation nécessite beaucoup de concentration. Avoir beaucoup de réunions au cours de la journée (même si cela ne dure que quelques minutes) empêche un développeur de devenir vraiment productif. Dans les faits, le passage d’une tâche à une autre en continu est l’une des principales causes de gaspillage de productivité.
Comment empêcher que Scrum soit qualifié d’« usine à réunions » ?
Plusieurs solutions sont possibles, comme :
- Les événements Scrum ne sont pas des réunions mais des opportunités de conversation.
Tobias Mayer décrit parfaitement cela dans son livre « The People’s Scrum » :
« Scrum est centré sur les personnes et les personnes ont des conversations. Il y a des conversations pour planifier, pour aligner et pour réfléchir. Nous avons ces conversations à des moments appropriés. Si nous n’avons pas ces conversations, nous ne saurons pas ce que nous devons faire (planification), nous ne saurons pas où nous dirigeons (alignement) et nous continuerons à répéter les mêmes erreurs inévitablement (réflexion/expérience). » - Respecter la durée des cérémonies.
Prenez par exemple le Daily Scrum : je pense que cet événement dépasse le plus souvent la durée fixée. Or le Daily Scrum, en particulier, est un événement que vous apprenez seulement à bien faire quand vous respectez la durée fixée de 15 minutes. La contrainte est nécessaire pour se synchroniser efficacement en tant qu’équipe et organiser sa journée pour la journée à venir. S’en tenir à une durée fixe, bien que l’objectif de la réunion n’a pas été atteint, oblige à s’auto-organiser ensemble pour trouver une solution pour le lendemain. - Préparez l’horaire des événements Scrum et assurez-vous que l’objectif est clair.
Communiquer l’ordre du jour suffisamment tôt pour donner à chaque membre de l’équipe l’opportunité de se préparer correctement. Précisez également quel type de préparation vous attendez de l’équipe, compte tenu de l’objectif de la session. Si quelqu’un doit effectuer une démo d’une fonctionnalité pendant la revue du sprint, communiquez-le dès que possible et réservez du temps pendant le sprint pour cette préparation. Un bon outil pour aider l’équipe à comprendre le but et les résultats attendus des rituels Scrum est fourni par Crisp avec le cube de réunion Agile. - Ne considérez pas l’affinage du backlog comme une réunion classique.
Le Guide Scrum décrit l’affinage comme l’ajout de d’informations, de détails, d’estimations et d’éléments au backlog du produit. L’affinement du backlog ne constitue pas un élément formel du cadre Scrum mais plutôt un processus en continu visant à améliorer la liste des fonctionnalités à adresser. Cela ne devrait pas être considéré comme une réunion mais bel et bien comme une activité de collaboration en équipe dans le but de préciser et compléter la description des prochains éléments à produire. Le conseil est de dépenser en moyenne 10% de la capacité de l’équipe de développement à affiner le backlog, la façon dont cela est fait n’est pas indiquée et dépend de l’équipe. - Utilisez des intervalles de temps « Ne pas déranger ».
Durant ces périodes exceptionnelles, l’équipe de développement est dispensée de toute réunion et ne sera dérangée que lorsque cela est vraiment urgent. Bien sûr, cela ne devrait pas interférer avec l’intention de collaboration et de communication transparente que l’équipe veut atteindre, mais un équilibre sain dans le but d’atteindre l’objectif attendu devrait être un objectif raisonnable. - Assurez-vous que le facteur ludique est présent.
Les rituels Scrum ou autres réunions non-Scrum ne doivent pas être ennuyeux, fastidieux et épuisants. Mon intention est toujours de favoriser le plaisir, l’énergie, l’interaction et la collaboration dans chacune des sessions. Pour obtenir cela, je restreins l’utilisation d’un projeteur et de diapositives PowerPoint au strict nécessaire, je mets les chaises en cercle et je minimise l’utilisation des ordinateurs portables. Ne considérez pas les rituels comme des réunions ordinaires. Un rituel est aussi l’opportunité de collaborer, d’apprendre et de s’amuser ensemble ! - Créez un calendrier de sprint.
Fournir de la transparence en créant un calendrier (ou planning) de sprint qui contient tous les rituels Scrum et les autres réunions peut être très utile. Il donne à l’équipe un aperçu de ce à quoi ils peuvent s’attendre pendant un sprint et aide à créer une planification quotidienne durant le sprint. Parfois, l’équipe estime avoir eu beaucoup de réunions, le calendrier de sprint permettra de casser factuellement ce sentiment. - Embrasser les réunions avec le client.
Dans l’esprit d’une approche Agile, la collaboration client est une partie essentielle du développement d’un produit. Ce ne devrait pas être une relation froide client-fournisseur, mais un partenariat où le client fait partie de l’équipe, avec le désir de créer également des produits marquants. Les réunions avec le client doivent donc être considérées comme une opportunité de comprendre le « pourquoi » et le « quoi » du produit et ainsi d’augmenter les chances de créer le bon produit.
Vous l’aurez compris, pour moi (Barry Overeem), Scrum n’est PAS une usine à réunions et encore moins un facteur contaminant de réunionite aigüe.
► Chaque rituel Scrum apporte systématiquement de la valeur ajoutée.
Ceci est une traduction libre de l’article « Scrum Myths: Scrum is « Meeting Heavy » » de Barry Overeem – Co-Fondateur de @The Liberators | Professional Scrum Trainer @Scrum.org
Vous avez aimé cet article ?
Laissez un commentaire positif et partagez-le sur les réseaux sociaux !
……… ✂……………………………… ✂………………………………… ✂………
Envie d’aller plus loin ?
- Le guide SCRUM en français
- Qui porte le rôle de chef de projet en agile ?
- Qui fait quoi dans une équipe Scrum ?
- [LIVRE] Scrum – Pour une pratique vivante de l’agilité, de Claude AUBRY
- [LIVRE] Scrum, de la théorie à la pratique, de Bassem EL HADDAD, Julien OGER
- Qu’est-ce qu’un Coach Agile ? Quel est son rôle ?
……… ✂……………………………… ✂………………………………… ✂………
