Étape indispensable du processus d’amélioration continue agile, la rétrospective nécessite l’adhésion des participants, et que tous puissent s’exprimer librement, sans contrainte ni crainte de représailles ou de moqueries. C’est l’occasion de faire le point sur le sprint écoulé, sur ce qui a bien fonctionné et sur ce qui a posé plus de problèmes. Mais il n’est pas toujours évident pour tout le monde de s’exprimer. Timidité, manque de confiance, peur de prendre la parole en public ? Il est parfois difficile d’amener tout le monde à s’exprimer. Nous allons voir 8 outils pour animer une rétrospective Agile Scrum qui peuvent aider le facilitateur à la rendre réellement productive.
Quelques rappels sur la rétrospective agile scrum
Programmée à la fin de chaque sprint, ces 8 outils pour animer une rétrospective Agile Scrum devraient en faciliter le déroulement. L’objectif est de parvenir à aider tous les membres de l’équipe à analyser les processus et les outils mis en œuvre durant le sprint qui vient de s’achever. Il est possible de cette façon de faire ressortir les points positifs, ce qui a bien fonctionné, et les points négatifs, qui ont pu nuire à la productivité de l’équipe.
Au terme de la rétrospective, un plan d’actions est mis en place, de façon à consolider ce qui a bien fonctionné, et à corriger les différents points négatifs. Chacun s’engage alors à mettre en œuvre ce plan d’actions durant tout le sprint suivant.
Pour être efficace, la rétrospective doit avoir une durée limitée, généralement 45 minutes par semaine de sprint, soit 1h30 si un sprint dure deux semaines. Afin de s’assurer que ce temps ne sera pas dépassé, un « gardien » pourra être désigné, qui aura la charge de rappeler régulièrement le temps déjà écoulé.
Tous les membres de l’équipe, du product owner au scrum master en passant par l’équipe technique, sont conviés à la rétrospective agile. C’est généralement le scrum master qui joue le rôle de facilitateur. En revanche, il est préférable qu’aucun manager n’assiste à la rétrospective, de façon à ce que les membres de l’équipe ne soient pas freinés dans ce qu’ils pourront exprimer et qu’ils décident librement et sans contraintes des actions à mettre en place.
La rétrospective Agile scrum se déroule généralement en trois grandes phases :
- la récupération des données,
- l’identification des problèmes et des solutions,
- et enfin, la définition d’un plan d’actions.
Outils pour la récupération des données
Afin de démarrer la réunion, il va falloir lancer les discussions, puis récolter les avis de chaque participant. Cela permettra d’obtenir une vision globale de ce qui s’est passé durant le sprint écoulé et le ressenti de l’équipe.
En guise d’introduction, le facilitateur peut rappeler à tous le principe de la rétrospective et son intérêt pour l’amélioration continue.
Le Mood Board
L’objectif ici est de mesurer les émotions et le ressenti de l’équipe. On affiche 5 images ou smileys sur un tableau, représentant chacun un niveau, de 1 (correspondant à un grand mécontentement ou à un profond malaise) à 5 (correspondant à une grande satisfaction).
Des post-it sont distribués aux participants, qui viennent chacun à leur tour coller leur post-it dans la colonne de leur choix. A la fin de l’exercice, on obtient un graphique représentant l’état d’esprit de l’équipe à l’issue du sprint.
1 mot
Cette technique est très utile pour relancer les discussions lorsque des dissensions apparaissent au sein de l’équipe.
Chaque participant exprime son sentiment sur le dernier sprint en un seul mot et l’écrit sur un post-it. Chaque mot est ensuite examiné, entraînant généralement l’ouverture de discussions et d’explications. C’est l’occasion pour chacun d’exprimer ses sentiments et ses émotions. C’est très libérateur et cela permet à l’équipe de traiter les problèmes en profondeur afin d’y apporter des solutions.
Le quadrant
Très facile à mettre en œuvre, cet exercice consiste à diviser un tableau un quatre parties de couleurs différentes qui regrouperont respectivement :
- Les points positifs.
- Les points à améliorer.
- Les « merci ! ».
- Les idées d’amélioration.
Chaque participant est muni de post-it correspondant aux couleurs des quatre zones et va pouvoir noter ses idées, ses impressions, son ressenti. A tour de rôle, chacun va pouvoir venir coller ses post-it dans les différentes zones.
Les deux premières parties sont faciles à comprendre. Elles représentent ce qui s’est bien passé, et ce qui s’est mal passé durant le sprint qui vient de s’achever.
Les « merci ! » sont là pour remercier ou mettre en valeur les actions, les idées ou les décisions d’une personne qui a permis de faire avancer le projet ou qui a aidé activement ses collègues.
Les idées d’amélioration sont celles qui sont venues durant le sprint, qui auraient pu faciliter la tâche de l’équipe, mais qui n’ont pas pu être mises en œuvre sur le moment.
L’exercice a une courte vocation, 5 à 10 minutes maximum pour la réflexion, puis pour coller les post-it. Le dernier à passer peut regrouper les idées et les remarques similaires ensemble. Il est également conseillé de fixer un temps limite pour que chacun puisse exprimer ses idées. Dans le cas d’une équipe nombreuse, il vaut mieux également fixer un nombre maximal de post-it par personne afin de pouvoir conserver un temps de parole suffisant à la fin.
Outils pour identifier les problèmes et leurs solutions
Les données recueillies à l’aide des exercices précédents permettent maintenant d’avoir une vision claire des problèmes rencontrés par l’équipe durant le sprint. Il est temps de proposer des solutions.
Le questionnement ORID
Le principe de cette méthode est de poser quatre types de questions aux participants :
- « O »bjective : on identifie précisément des faits, ce qui s’est passé.
- « R »eflective : on identifie le ressenti de chacun pour les faits énoncés.
- « I »nterpretive : on partage son interprétation des faits, ce qu’ils signifient.
- « D »ecisional : on identifie les différentes actions qui peuvent être entreprises pour éviter que les faits décrits ne se reproduisent à l’avenir.
L’objectif de la méthode ORID est de rendre la discussion constructive, en la guidant, jusqu’à obtenir un plan d’actions pour les prochains sprints.
Les 5 pourquoi ?
Cet exercice très simple consiste à se poser 5 fois d’affilée la question « pourquoi » à propos d’un problème identifié. Par exemple, un développeur s’est retrouvé dans l’incapacité de travailler durant plusieurs heures.
- Pourquoi le développeur a-t-il été dans l’incapacité de travailler ?
Parce qu’il ne pouvait pas utiliser sa version de travail de l’application. - Pourquoi ne pouvait-il pas utiliser sa version de travail de l’application ?
Parce que sa version de l’application ne fonctionnait plus. - Pourquoi sa version de l’application ne fonctionnait-elle plus ?
Parce que ses tests ont fait apparaître une anomalie majeure et bloquante. - Pourquoi n’a-t-il pas restauré la version précédente de l’application pour repartir sur des bases saines ?
C’est ce qu’il a fait, mais il n’y a pas de procédure automatisée, juste une procédure manuelle qui peut prendre plusieurs heures. - Pourquoi n’y a-t-il pas une procédure automatique de restauration d’une version de l’application ?
En répondant à 5 questions « pourquoi », on arrive en général à identifier la cause réelle du problème, qui est bien souvent masquée par d’autres problèmes. Une fois les racines du mal identifiées (ici, l’absence de procédure automatisée et rapide), il est plus facile de trouver une solution.
Outils pour la définition du plan d’actions
Nous avons à ce stade identifié les problèmes rencontrés ainsi que les causes, et nous avons une liste d’actions potentielles à mettre en place. Il faut maintenant décider quelles actions vont réellement être mises en œuvre lors du prochain sprint (sans oublier de prendre en compte les actions identifiées lors de la rétrospective du sprint précédent et qui n’avaient pas été retenues).
Start / Stop /Continue
Il s’agit sans doute de la méthode la plus simple. Le tableau est séparé en trois colonnes :
Start : les actions que l’équipe souhaite mettre en place.
Stop : les actions qu’elle souhaite arrêter (parce qu’elles n’ont pas porté leurs fruits par exemple).
Continue : les actions déjà en place, mais que l’on souhaite poursuivre, soit parce qu’elles sont efficaces, soit parce qu’elles n’ont pas encore apporté tous les bienfaits qu’elles auraient dû.
Chacun peut s’exprimer et placer les actions à sa convenance dans les différentes colonnes. A la fin, soit un consensus se dégage, soit un vote départagera les différentes actions.
Le starfish
Le starfish est une version améliorée sur Start / Stop / Continue auquel on a ajouté deux zones supplémentaires (les cinq zones sont alors disposées en « étoile de mer » de façon à faciliter la lecture du tableau.
Les deux zones supplémentaires sont « faire moins » (les activités à réduire, sans toutefois les arrêter complètement) et « faire plus » (les activités à augmenter).
Speed boat
Le projet est symbolisé par un bateau sur lequel se trouve l’équipe. Il est dessiné au tableau, et les actions, toujours sur des post-it, vont être représentées de la façon suivante :
- Les freins à l’avancement du projet sont représentés par des ancres (problèmes qui ralentissent la réalisation, insatisfactions des utilisateurs ou des clients…). Plus elles sont positionnées bas sur le dessin (et donc profondément sous la surface), et plus les nuisances sont importantes.
- Les actions ou les événements qui au contraire font avancer le bateau sont représentés par le vent qui gonfle les voiles ou les moteurs qui propulsent le bateau et le font avancer.
Pour conclure sur les outils de rétrospective agile scrum
La rétrospective agile scrum est un outil précieux pour améliorer sans cesse la productivité et l’efficacité de l’équipe tout au long du projet. Le fait de pouvoir faire un bilan à la fin de chaque sprint permet d’aller de l’avant et de ne pas retomber dans les erreurs déjà commises par le passé.
N’hésitez pas à tester gratuitement durant 14 jours le logiciel Scrum Nutcache, qui intègre tous les outils nécessaires à l’animation et à la gestion des réunions de rétrospectives agiles scrum.
