Je crois qu’il n’y a pas une seule équipe ou entreprise où je sois passée qui ne se soit plaint à un moment ou à un autre d’avoir trop de réunions. Et perso, je trouve souvent que ce sont des “faux” problèmes…
Premièrement, c’est une affirmation extrêmement subjective, un développeur va peut-être considérer que s’il passe 1h/ jour en réunion c’est énorme, alors qu’un Product Manager qui passe plus des 3/4 de sa journée en réunion va trouver ça normal. Donc pour aller chercher les “vraies” causes de ce qui fait râler, je n’ai pas encore trouvé mieux que d’aller examiner avec eux leur agenda pour voir ce qui leur pose problème. On entre alors plutôt dans une démarche de coaching en allant chercher avec ces personnes quelles sont les causes de leur ressenti et pourquoi ils ont l’impression de perdre du temps en réunion. Cette phase d’analyse est souvent utile pour comprendre la perception du problème et aller ensuite vers une approche plus systémique.
Si on prend un exemple classique d’une équipe qui fait des sprints de 2 semaines, voilà globalement les rituels qu’ils ont la plupart du temps :
- Sprint planning = 1h / Sprint
- Daily Scrum = 15min / jour = 2,5h / Sprint
- Product Backlog refinement = 1h / Sprint
- Sprint Review = 1h / Sprint
- Rétrospective = 1h / Sprint
Ca nous fait donc un total de 6,5h de réunions imposées à minima par sprint de 2 semaines. Donc environ 10% du temps du sprint est dédié à du temps de travail collaboratif. Personnellement (encore une fois, c’est subjectif), ça ne me paraît pas énorme au vu de la valeur de ces rituels. Souvent, le problème n’est pas là…
La réunionite est très aigüe notamment lors d’une transformation, lorsque l’équipe est amenée à changer son cadre de travail et donc à mettre en place de nouveaux rituels. Au lieu de “remplacer” l’ancien cadre de travail par le nouveau, on l’a juste “additionné”. On se retrouve donc de manière soi-disant temporaire (piège) avec des réunions en doublon !
Avant la transformation agile, on pouvait avait des kick-offs, des comités de pilotage, des revues de projet, des points d’avancement, chacune de ces réunions ayant un objectif précis aligné avec le cadre de travail de l’équipe. L’équipe fonctionnant dorénavant en Scrum, elle a donc adopté le sprint planning, le daily scrum, la sprint review et la rétrospective, mais a maintenu en même temps des réunions de l’ancien mode de fonctionnement, avec un certain nombre de doublons et une perte de sens du nouveau framework.
C’est un signe assez important pour identifier du Zombie Scrum : les rituels ont bien lieu, le vocabulaire utilisé est le bon, mais dans le fond rien n’a vraiment changé ! Les parties prenantes ne viennent pas en sprint review pour travailler avec l’équipe et leur donner des feedbacks, la planification se fait dans des réunions en amont du sprint planning, les décisions se prennent dans des instances de pilotage éloignées de l’équipe. L’équipe ne comprend pas l’intérêt du nouveau framework qu’ils accusent de créer des pertes de temps, et tout le monde se noie sous des process vidés de sens. C’est le cas également quand l’organisation a un mode de fonctionnement éloigné de celui de l’équipe. Les personnes à l’extérieur de l’équipe ne comprennent pas les rituels et on en crée donc de nouveaux, plus alignés avec leur compréhension et plus proche de leur fonctionnement habituel.
Pour éviter cet effet combiné “Zombie Scrum / Réunionite”, il faut bien travailler la compréhension du “pourquoi” de chaque rituel, définir qui doit y participer et ce qu’on attend de chaque participant pendant cette réunion. Et faire ça AVEC les parties prenantes bien sûr, voire même en commençant par eux !
Un des apports du Scrum Master dans ce cas peut être de construire une “Stakeholder map” et d’aller identifier les besoins des parties prenantes, et comment y répondre de manière efficace avec des rituels alignés.
Nos process sont là pour répondre à un besoin, et s’inscrivent dans une approche globale. Pour le cas de Scrum par exemple, chaque pilier, chaque valeur, chaque rituel, chaque artefact et chaque rôle a un sens précis et apporte une partie des réponses. Si on change quelque chose dans la manière d’utiliser certaines parties ou si on décide de n’en utiliser qu’une partie, il faut bien réfléchir en terme d’alignement global si ce qu’on fait a toujours du sens. Ne pas faire de sprint review parce que les incréments sont montrés aux parties prenantes dans d’autres instances peut certes faire gagner du temps de réunion, mais peut être contre-productif à bien d’autres égards (engagement de l’équipe, portée des feedbacks reçus, manque de transparence des décisions, etc).
Donc avant de se demander comment diminuer le temps passé en réunion, je propose plutôt d’essayer d’optimiser le temps qu’on y passe en réfléchissant aux vrais objectifs de cette réunion. Ensuite on pourra réfléchir à comment optimiser ce temps et à atteindre ces objectifs de manière plus frugale.
Amis Scrum Masters, si en rétrospective, vous constatez que les seules problèmes qui ressortent sont une perception qu’il y a trop de réunions, ne vous laissez pas berner : creusez, challengez, allez voir pourquoi les membres de l’équipe ont la sensation de perdre leur temps en réunion. Vous allez certainement déterrer des racines profondes, et décupler les impacts de vos actions d’amélioration !
Quelques questions à se poser dans ce cas-là :
⭐ Commencez par vous demander si vos réunions ont un sens
Chaque rituel de Scrum répond à un objectif précis. Donc avant d’en supprimer ou détourner une partie pour gagner du temps, posons nous la question de son objectif dans notre framework :
❓Est-ce que l’objectif est clair, partagé et transparent pour tous les participants ?
❓Est-ce que notre manière de mener ce rituel répond à son objectif ?
❓Est-ce que d’autres réunions hors Scrum ont en fait le même objectif ?
⭐ Appliquez les principes lean : cherchez ce qui n’apporte pas de valeur
Une fois que la question du sens dans le cadre de notre framework global est abordée, on peut commencer à regarder si on peut répondre à ces objectifs de manière plus frugale.
❓ Que peut-on améliorer dans notre façon d’atteindre les objectifs de nos rituels ?
❓ Que fait-on en double ou avec le mauvais niveau de qualité (trop ou pas assez quali) ?
❓ De qui a-t-on besoin de se rapprocher pour être plus efficace ?
⭐ Appliquez les principes agiles :
➡️ Les process et les outils doivent être au service de nos interactions
❓ Quels sont les process que je n’applique que pour le process lui-même ?
❓ Avec qui devrais je avoir plus d’interactions ? Est-ce que mes réunions me permettent ces interactions aujourd’hui ?
➡️ La collaboration avec clients et parties prenantes est plus importante que juste respecter le process
❓ Est-ce que mes réunions me permettent de collaborer avec les bonnes personnes ?
❓ Est-ce que pour vraiment collaborer j’ai besoin de sortir de mon process ? Est-ce que ça m’est permis ?
❓ Est-ce que je peux faire évoluer mon process pour mieux collaborer ?