Nous partageons très régulièrement sur ce blog notre expertise technique autour du développement et de l’architecture web et mobile. Aujourd’hui, j’aimerais aborder un autre sujet, tout aussi important : notre expertise méthodologique.
Chez Eleven Labs, notre méthodologie agile repose principalement sur la méthode SCRUM. J’aurais l’occasion de partager d’autres articles pour décrire cette méthodologie et ses outils plus en détails. Nous allons parler ici d’un must-have de toutes les méthodologies agiles, très probablement la cérémonie agile la plus mise en pratique : la rétrospective.
Dans cet article, on parlera plus particulièrement d’une rétrospective de sprint SCRUM dans le cadre d’un projet informatique mais la plupart des outils mentionnés ici sont utilisables pour n’importe quelle méthodologie agile et la majorité des projets.
En fin de sprint, ou fin de cycle de développement, quand le but de la démonstration (“Sprint review”) est d’analyser l’incrément de produit développé pendant cette itération, i.e. le “quoi”, le but de la rétrospective est d’analyser les processus et outils utilisés pour arriver à cette fin, i.e. le “comment”.
L’objectif final est donc de rendre l’équipe encore plus productive pour la prochaine itération. Autrement dit, le but est d’augmenter la vélocité (nombre de points livrés par l’équipe à chaque itération) et la qualité du produit.
Concrètement, les discussions de cette réunion doivent ainsi permettre d’établir un plan d’actions d’améliorations, que l’équipe doit s’engager à suivre lors de la prochaine itération. Ces actions peuvent être décrites sous la forme de “Stories” techniques ou “improvements” priorisés au sein d’un backlog dédié, et chacune peut être assignée à un membre en particulier qui s’engage alors à réaliser cette tâche. Cela implique qu’une capacité dédiée doit être réservée pour pouvoir gérer ces actions en parallèle des actions de production (“User Stories” fonctionnelles du Sprint).
Chaque jour nous avons bien-sûr des occasions d’améliorer nos outils ou process. Cependant toute équipe se laisse assez facilement emporter par les urgences du quotidien et il est donc important de dédier un moment régulièrement pour que l’équipe prenne du recul et trouve le moyen de s’améliorer sur le long terme.
Ce moment dédié se prend donc généralement à la fin de chaque itération (Sprint ou Release par exemple), pour repartir sur de bonnes bases à la prochaine.
On parle ainsi de cycle d’amélioration continue : à chaque itération, on apprend de nos expériences et on adapte notre organisation au fur et à mesure.
Que ce soit en début de projet, ou même après plusieurs années, une équipe peut toujours faire mieux. Ainsi il vaut mieux avoir une équipe capable d’apprendre et de toujours s’améliorer plutôt qu’une qui reste au même niveau.
Comme chacune des réunions agiles, pour plus d'efficacité, la rétrospective doit toujours être définie et limitée dans le temps : time-boxée.
Évidemment pour que cette durée maximale soit respectée, il faut que celle-ci soit annoncée clairement avant de commencer. De plus, un membre de l’équipe peut jouer le rôle de “gardien du temps” qui devra informer régulièrement l’équipe du temps passé et restant. Attention, son rôle est seulement de notifier l’équipe et en aucun cas de couper les conversations pour imposer son timing.
On convient généralement que ce rituel ne doit pas dépasser 45 minutes par semaine de Sprint, soit 1 heure 30 pour des itérations de 2 semaines. Il peut être bien de réduire cette durée maximale à 1 heure pour une équipe plus expérimentée.
Pour les équipes un peu plus nombreuses, si on veut réduire cette durée totale tout en laissant la parole à chacun, il peut être bien de time-boxer le temps de parole de chacun, ou de diviser l’équipe en plusieurs petits groupes. Nous pourrons détailler ces techniques par la suite.
Tous les membres de l’équipe de réalisation (développeurs, testeurs…) ainsi que le Product Owner (ou Product Manager) participent à cette rétrospective. Ainsi l’équipe profite de ce rituel pour améliorer ses process de développement et le Product Owner va chercher à améliorer sa communication ou l’expression de ses besoins, pour que l’ensemble de l’organisation soit plus productive.
De manière générale, toute partie prenante qui travaille au quotidien en relation avec l’équipe de réalisation peut participer. Par exemple, il peut être intéressant de faire participer le responsable de l’infrastructure qui livre en production le produit de l’équipe, si celui-ci n’est pas intégré dans l’équipe de réalisation. Il est important que celui-ci soit impliqué le plus possible dans ce cycle d’amélioration continue puisque, pour que l’équipe soit plus productive, il faut non seulement qu’elle produise plus, mais également que son produit soit livré sur l’environnement final.
De son côté, le SCRUM Master joue le rôle de facilitateur : il fournit les outils et aide l’équipe à s’organiser pour mener la discussion et établir son plan d’actions. Son rôle est important surtout en début de projet mais, avec de l’expérience, l’équipe auto-organisée devrait être capable de mener cette rétrospective sans lui. Cela permet ainsi au SCRUM Master de se concentrer sur les perturbations extérieures à l’équipe plutôt que sur les décisions d’améliorations internes.
Quoi qu’il en soit, pour que le plan d’actions de fin de rétrospective soit réalisable et que l’équipe puisse s’engager sur son application, il est préférable qu’elle l’ait établi sans contrainte et qu’il n’ait donc pas été imposé par la direction. Il vaut donc mieux qu’aucun manager ne participe à cette réunion. Si le rôle de SCRUM Master est tenu par un chef de projet ou manager, il faudra donc que celui-ci se limite à son rôle de facilitateur et laisse l’équipe décider librement de ses actions.
Pour bien animer cette rétrospective, il existe différents outils permettant de mener la discussion jusqu’à l’établissement du plan d’actions d’améliorations. En voici quelques uns, à utiliser à différentes étapes de la rétrospective :
La première étape est de lancer la discussion puis de recueillir les avis de chacun et obtenir une bonne vision de ce qui s’est bien ou moins bien passé pendant cette itération.
Avant de commencer la moindre discussion, il peut être bien d’avoir une vision globale du ressenti de chaque membre de l’équipe. Ainsi on peut demander à chacun de se donner une note de 1 à 5 :
Pour que ces notes soient objectives, il faut que celles-ci soient données anonymement. Le facilitateur peut ensuite rassembler les résultats de ce vote et les communiquer à l’équipe qui pourra les interpréter.
Le but est bien sûr d’obtenir une note moyenne la plus haute possible pour faire avancer au mieux la discussion.
Si l’équipe n’est globalement pas suffisamment à l’aise pour discuter des sujets, éventuellement durs, qui doivent être abordés, le facilitateur pourra rassurer les membres de l’équipe en ré-expliquant l’objectif de ces rétrospectives et de l’amélioration continue. Il pourra aussi être envisagé de diviser l’équipe en petits groupes pour favoriser le dialogue. Il se peut également que ce soit la présence d’un manager qui diminue la note globale de confiance de l’équipe.
De la même façon, les 5 notes du Safety Check précédent peuvent être représentées de manières plus ludiques à l’aide d’images, de personnages ou smileys plus ou moins confiants.
En cas de problème majeur, il se peut qu’un seul mot suffise pour lancer la discussion. Avec l’expérience, le facilitateur sera capable de ressentir ce genre de situation avant même de débuter la rétrospective et pourra proposer aux membres de l’équipe d’inscrire un seul mot sur un post-it, pendant une durée limitée, avant que chaque membre l’exprime et l’explique devant toute l’équipe.
La manière la plus courante, et aussi souvent la plus efficace, est de demander à chacun de synthétiser ses idées sur des post-it suivant différentes catégories :
Quelques soient ces catégories, l’idée est de définir une courte durée (5 ou 10 minutes) pendant laquelle chacun met ses idées sur ses post-it. Ensuite chacun à son tour va les coller sur le tableau, dans la bonne catégorie, et expliquer à l’équipe chacun de ses points. Le dernier à s’exprimer, ou autre volontaire, pourra ensuite regrouper les idées similaires pour donner une meilleure vision globale.
Pour les équipes plus nombreuses, ce genre d’exercice peut prendre trop de temps, il peut alors être bien de limiter le nombre de post-it autorisés par personne pour forcer chacun à être plus concis. De la même manière, on peut définir un temps de parole maximum par personne pour présenter ses idées.
De manière générale, pour redynamiser les équipes qui peuvent être habituées à une unique forme de rétrospective, il peut être intéressant de changer régulièrement la technique utilisée parmi celles décrites précédemment.
De plus, pour favoriser encore la communication et la compréhension des problématiques rencontrées par chacun, on peut pratiquer cet exercice : le facilitateur demande à chaque membre d’écrire ses points (répartis par catégories comme décrit précédemment) et de les lui remettre. Le facilitateur peut ensuite faire passer ces post-it à un autre membre, sans indiquer qui les a écrits. Celui-ci devra alors les interpréter et les expliquer devant l’équipe comme s’il les avait écrits lui-même, avant d’essayer de deviner qui les a initialement décrits.
Toujours pour inciter chacun à se mettre à la place des autres, une autre variante consiste à demander à chacun d’écrire deux mots, décrivant son ressenti, sur deux post-it différents qu’il passera à ses deux voisins, à sa droite et à sa gauche. Ensuite chacun, à son tour, essaie d’interpréter et expliquer ces deux mots reçus.
Pour récolter toutes les données d’une itération, on peut aussi demander à l’équipe de retracer l’historique du Sprint, depuis le planning jusqu’à la rétrospective. Ainsi chacun vient ajouter ses faits marquants sur la ligne temporelle tracée sur le tableau, en expliquant chaque fait, positif ou négatif.
Une itération de type Sprint SCRUM étant de courte durée, cette technique n’est pas toujours cohérente, puisqu’il n’est pas toujours simple de placer au bon endroit sur la timeline un fait du sprint. Cet exercice est donc généralement plutôt utilisé sur une échelle de temps plus importante, pour une rétrospective release ou un projet entier par exemple.
Les techniques précédentes permettent ainsi d’avoir une bonne vision des problèmes rencontrés par l’équipe. Avant d’établir un plan d’actions d’améliorations, il nous faut trouver des solutions pour chacun de ces points.
À l’étape précédente, nous avons vu que chacun pouvait, de différentes façons, exprimer ses différents points positifs et négatifs devant l’équipe.
Quand il est nécessaire de re-motiver l’équipe, le facilitateur peut demander à chacun d’aller un peu plus loin dans son analyse individuelle en demandant de transformer chaque point négatif en un point positif et au moins une idée d’amélioration. Ainsi chacun ira présenter exclusivement des points positifs et des améliorations devant l’équipe.
En plus de remonter le moral des troupes, cette technique permet d’arriver plus rapidement à la recherche de solutions qui permettront d’établir notre plan d’actions.
Le but de cette méthode est de guider l’équipe en lui posant successivement 4 types de questions, pour qu’elle décide ensemble des actions à mener. Voici ces 4 étapes :
Ce framework de facilitation permet de guider la discussion, de la rendre très constructive et donc d’obtenir un plan d’actions d’améliorations rapidement.
Enfin, cette dernière technique très simple consiste à demander “Pourquoi” cinq fois de suite quand un problème a été identifié, jusqu’à en arriver à la vraie cause du problème, qui est souvent masquée. Une fois la cause “racine” connue, on peut plus facilement trouver la solution à apporter.
Si vous avez bien pratiqué les techniques précédentes, vous avez maintenant une bonne vision des problèmes rencontrés par l’équipe et avez identifié de potentielles solutions et améliorations. Ils s’agit donc maintenant de vous mettre d’accord sur un plan d’actions.
Rappelons-le, l’équipe auto-organisée doit décider seule de ces actions et elle s’engage à les réaliser dans les temps. Ces décisions ne doivent pas être imposées par un manager.
Il est préférable de privilégier la qualité à la quantité d’actions : il sera donc suffisant de s’engager sur deux ou trois actions vraiment impactantes à réaliser d’ici la prochaine rétrospective.
Une des première chose à faire, avant de décider du prochain plan d’actions est de vérifier que toutes les actions de la précédente rétrospective ont bien été réalisées. Si non, peut-être qu’elles ne sont plus d’actualité ou que l’équipe n’a pas pu consacrer assez de temps à ces actions d’amélioration ou que personne n’a été assigné à cette tâche. Dans tous les cas, cette relecture donnera des indications et peut-être d’autres idées avant d’établir le prochain plan d’actions.
Si beaucoup d’idées d’améliorations ont été mentionnées, il va donc falloir sélectionner les meilleures ! Pour ce faire, le plus simple est de demander à chacun de donner son vote sur ses idées préférées : chacun a le droit de voter pour au plus 3 idées par exemple, puis les 3 idées ayant obtenues le plus de votes sont ensuite sélectionnées.
Il n’existe pas de petites améliorations ! Si vous manquez d’idées ou que tous vos process et outils sont déjà bien en place, essayez de penser aux petites améliorations qui pourraient vous faire gagner 2 secondes tous les jours : raccourcis clavier, tâches automatisées...
J’espère que cet article vous aura donné de nouvelles idées pour animer vos prochaines rétrospectives, pour ceux d’entre vous qui ont déjà l’habitude d’en faire. Il peut même être intéressant pour vous de faire des rétrospectives de rétrospectives, pour rendre ces dernières toujours plus ludiques et productives !
Pour les autres, j’espère que cela vous aura donné l’envie de pratiquer ces exercices pour mettre en place vos premiers cycles d’amélioration continue. Même s’il peut vous sembler délicat de parler ainsi librement des problèmes que vous rencontrez, potentiellement avec d’autres membres de votre équipe, lancez-vous. Discutez sans contrainte, et vous verrez, quand la discussion est bien menée avec ces outils, c’est toujours très productif !
N’hésitez pas à partager vos expériences de rétrospectives en commentaires ci-dessous.
Sources :
Auteur(s)
Charles-Eric Gorron
Software Solution Architect, Team Leader & Studio Director @ Eleven Labs
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
La qualité est un enjeu très important dans le développement logiciel, cet article vous permettra de (re)découvrir les impacts de la non-qualité, les bienfaits de la qualité et les bonnes pratiques qualité.
Aujourd’hui on parle de product management pour qualifier tout et n’importe quoi, ce qui entraîne la mise en place d’organisations produits sur des bases bancales. Quelles sont les principales erreurs commises ? Comment les éviter ? La liste n’est pas exhaustive mais vous permettra assurément de mieux appréhender votre méthodologie produit.
Cet article présente mes méthodes préférées pour bien appréhender un nouvel environnement de travail, incluant des outils pratiques comme le rapport d'étonnement, le Value Stream Mapping, le mandat de mission, la matrice des attendus et les Moving Motivators, afin de faciliter l'intégration, améliorer les processus et renforcer la collaboration au sein de l'équipe