Pourquoi cet article ?
Le manifeste Agile établit 4 valeurs et 12 principes pour établir un cadre de travail Agile. Dans les faits, la plupart des projets vont utiliser une méthode, Scrum ou Kanban dans la grande majorité, qui définissent des méthodes de travail pour mettre en œuvre les valeurs et principes du manifeste Agile.
Dans cet article nous aborderons les différentes réunions proposées par ces méthodes en tentant de garder à l’esprit la valeur numéro 1 du manifeste Agile : les individus et les interactions plus que les processus et les outils. L’objectif étant d’analyser l’intérêt de ces processus et outils au service des interactions entre les individus de l’équipe.
Les cérémonies Agile
Afin de simplifier, j’ai tenté de réunir les réunions Scrum et Kanban sous des noms génériques qui peuvent s’appliquer aux deux méthodes. Pour cet article, je considère une équipe composée ainsi :
- Un PO : product owner, responsable du backlog et des liens avec le ou les clients et commanditaires
- Une équipe de développement : des développeurs-euses front et/ou back, des devops, des testeurs-euses, des analystes fonctionnels … ceux qui permettent de produire un package de livraison
- Un coach agile : il est là pour faire respecter les règles que l’équipe a décidé de s’auto-appliquer. Une équipe agile mature doit pouvoir s’affranchir du coach et faire respecter les règles elle-même
Le daily
- Fréquence : tous les jours sans exception
- Durée : 15 minutes
- Participants : l’équipe de développement (PO facultatif)
- Objectifs :
Le daily sert à ce que toute l’équipe partage l’avancement des sujets et les points de blocage éventuellement rencontrés. Un outil de visualisation des tâches est souvent utilisé pour permettre à toute l’équipe de comprendre quelles sont les tâches à venir, en cours et celles qui sont terminées.
Le partage des points de blocage doit permettre à l’équipe de s’organiser sur la journée pour y répondre, on ne tente pas de régler les problèmes au daily mais on planifie les actions à prendre et les membres de l’équipe concernés (on aura peut-être besoin du PO si la question est fonctionnelle ou d’un expert technique) : une réunion, du pair programming, un changement du responsable de la tâche, une spécification à préciser, …
La planification
- Fréquence :
- Scrum : 1 par sprint (avant le sprint)
- Kanban : en fonction des besoins de remplissage de la colonne à faire
- Durée : entre 1h et 2h
- Participants : toute l’équipe
- Objectifs :
Les réunions de planification servent à définir quelles seront les prochaines tâches à réaliser.
A partir du backlog produit, on identifie les tâches qui sont prioritaires par rapport aux besoins des utilisateurs (ou des commanditaires) et qui sont suffisamment précise pour que l’équipe de développement soit en capacité de réaliser la tâche. Cette étape nécessite en réalité des prérequis : un backlog priorisé par le PO et des spécifications claires et précises permettant le développement et la recette.
Au cours de la planification, l’équipe de développement peut mettre en place un exercice d’estimation des tâches en point d’effort (planning poker par exemple) afin de mieux identifier la charge acceptable pour une itération donnée.
Grâce à cette réunion l’équipe est donc informée du travail à accomplir et confirme au PO sa capacité à produire ce qui est attendu.
Pour une planification réussie, il peut être utile d’organiser une réunion préalable entre le PO, le lead développeur et la recette : les 3 amigos. Cette réunion permet de s’assurer que la spécification est suffisamment précise pour le développement et la phase de recette.
La revue
- Fréquence :
- Scrum : 1 par sprint (après le sprint)
- Kanban : lorsque l’on décide de livrer une version
- Durée : entre 1h et 2h
- Participants : toute l’équipe + les partie-prenantes (utilisateurs ou commanditaires)
- Objectifs :
La revue d’itération ou revue du livré permet d’identifier le travail réalisé depuis la dernière planification et d’assurer la qualité des réalisations.
On reprend chaque tâche et on montre le résultat obtenu pour s’assurer que les besoins du client sont satisfaits. C’est l’opportunité pour échanger directement avec le client sur la réalisation et parfois d’enregistrer une évolution complémentaire ou un autre besoin.
En parallèle, cette réunion sert également à s’assurer que ce qui est envoyé en production est de qualité suffisante pour le client.
Au sein d’une équipe Scrum, cette réunion peut servir à échanger sur les difficultés qui ont empêché la réalisation d’une tâche et aussi à affiner le nombre de point d’effort qu’un sprint peut contenir.
La rétrospective
- Fréquence :
- Scrum : 1 par sprint (après le sprint)
- Kanban : de manière régulière, à décider avec l’équipe
- Durée : environ 2 heures
- Participants : toute l’équipe
- Objectifs :
La rétrospective est l’incarnation de l’amélioration continue au sein d’une équipe Agile, elle permet de partager en confiance et bienveillance les réussites et problématiques rencontrées sur une période de temps fixe, analyser les raisons de ces problèmes et identifier des actions pour les résoudre.
Il existe une multitude de format pour organiser une rétrospective, chacun permettant de mettre en exergue un ou plusieurs aspects de l’organisation de l’équipe. Un modèle classique de rétrospective comprend plusieurs étapes :
- Une introduction : on revoit les actions de la précédente rétrospective et on vérifie qu’elles ont été bien réalisées
- Une collecte des informations : chaque participant doit pouvoir s’exprimer sur les sujets de son choix concernant le fonctionnement de l’équipe
- Une phase de filtrage : l’équipe vote pour identifier un nombre restreint de sujets qui seront discutés (malheureusement on ne peut pas tout traiter en une rétro)
- Une génération de solution : l’équipe échange sur les sujets et tente d’identifier des actions pour résoudre les problèmes
La décision : l’équipe décide collectivement de prendre un certains nombres d’actions (il faut limiter à trois ou quatre en général) à réaliser avant la rétrospective suivante.
Bien entendu les durées et fréquences ne sont que des propositions, chaque équipe doit adapter son utilisation des méthodes en fonction de leur contexte et de la composition de leur équipe, l’auto-organisation étant au cœur du message porté par le manifeste agile.
Gladys NIARFEIX