Animez vos rétrospectives – Première partie

La rétrospective est l’une des cérémonies préconisées dans les méthodologies de développement agile. Son rôle est de permettre aux équipes de développement, et aux individus qui la composent, de continuellement s’améliorer.

Les rétrospectives pourront ainsi aider les équipes à améliorer leur productivité mais aussi les compétences de ses membres ou encore la qualité de ce que l’équipe produit. Leur but va donc bien au delà d’une analyse post-mortem d’une itération de développement de laquelle découlerait une amélioration des processus de développement.

Dans cet article, nous allons vous donner quelques clés pour vous aider à comprendre les enjeux et à mieux piloter vos rétrospectives.

L’origine des rétrospectives : le Kaizen ou la pratique Lean de l’amélioration continue

La rétrospective telle que nous la connaissons dans les méthodologies de développement agile tire son inspiration dans le milieu industriel et plus particulièrement automobile avec l’outil nommé Kaizen venant du Japon et faisant partie de l’outillage de la méthodologie Lean. Le Kaizen, littéralement « changement bon » est une méthodologie d’amélioration continue dont Toyota fut l’un des précurseurs.

Le Kaizen repose sur différents principes :

• tenter d’améliorer chaque règle de travail (working agreements),
• développer les compétences et l’implication de toute l’équipe,
• se focaliser sur la cause racine des problèmes,
• améliorer les processus afin de gagner en productivité.

Cette démarche de développement continu introduit le changement de manière graduelle et ne repose donc pas sur des réformes complètes et brutales du système du type «on efface tout et on recommence». Dans cette démarche, chaque travailleur est impliqué et est force de proposition pour améliorer sa manière de travailler.

Les méthodes agiles ont repris ce principe pour l’intégrer au sein du cycle de développement. Dans la méthodologie agile Scrum par exemple, une itération de développement, est constituée de différentes cérémonies :

• une session d’estimation en début d’itération,
• un stand up meeting chaque jour,
• une démonstration des fonctionnalités développées,
• une rétrospective.

La rétrospective est donc une partie intégrante du cycle de développement, et du travail de l’équipe.

Pourquoi mettre en place une démarche d’amélioration continue ?

Nous vivons dans un monde où les besoins de nos clients, les technologies ou encore la concurrence évoluent en permanence. Dans ce contexte, il est donc nécessaire de faire évoluer nos méthodes de travail afin de rester en phase avec les attentes du marché.

De plus, le fonctionnement d’une équipe est rarement parfait, il peut exister des tensions, des malaises, des regrets et d’autres sources de démotivation que les rétrospectives peuvent aider à découvrir et à traiter. La motivation d’une équipe est effectivement quelque chose qui s’entretient en supprimant les causes de démotivation, et non en essayant de motiver coûte que coûte en faisant fi des problèmes.

Différents axes de progression sont possibles lorsque l’on cherche à améliorer le fonctionnement d’une équipe de développement comme par exemple :

• la productivité de l’équipe,
• les compétences et les connaissances de chacun,
• la cohésion de l’équipe et la collaboration de ses membres,
• la communication interne ou externe,
• la qualité de ce qui est produit,
• l’intérêt et la motivation des collaborateurs,
• les règles de travail (working agreements),
• etc.

Cette liste est loin d’être exhaustive et bien d’autres axes de progression peuvent être abordés au cours des rétrospectives.

Les rétrospectives permettent d’explorer différents axes de progression et permettent aux équipes de s’accomplir au mieux dans chacun d’eux. Avant de continuer, nous allons nous intéresser à la manière dont l’un de ces axes pourrait être abordé et ce qui pourrait en découler.

L’amélioration de la productivité de l’équipe

Avec l’évolution actuelle des méthodes de développement, qui portées par des mouvements tels que le Craftsmanship tendent à nous orienter vers une culture du travail bien fait, la recherche de la productivité pourrait être perçue comme allant à contre courant. Bien évidemment il n’en est rien si on part du principe que cette recherche de productivité ne va pas à l’encontre de la qualité et si elle s’inscrit dans la durée. En effet, une mauvaise productivité peut être le signe de nombreux problèmes que les rétrospectives peuvent aider à mettre en exergue et à résoudre.

Pour commencer, qu’appelle-t-on « mauvaise productivité » et qu’est ce qu’une « bonne productivité » ? Ces notions sont particulièrement subjectives et il est difficile d’établir une règle permettant de les définir. Nous recommandons donc de s’attacher à étudier l’évolution de la vélocité de l’équipe de développement plutôt que sa valeur absolue. Cette notion de vélocité est utilisée dans des méthodes de développement agile comme Scrum. Elle représente la somme de travail effectuée sur des tâches terminées (selon la Definition of Done de l’équipe).
Une évolution à la hausse de cette vélocité peut indiquer une prise de maturité de l’équipe par rapport au projet, un projet sain etc.
En revanche, une évolution à la baisse pourra soulever des problèmes de qualité (probablement dûs à une dette technique élevée), des conflits au sein de l’équipe, des problèmes d’organisation, etc.

L’étude de cette évolution devra se faire sur plusieurs itérations afin de permettre à l’équipe d’en tirer des conclusions pertinentes. En effet, une vélocité en dents de scie pourrait par exemple mettre en avant des développements rapides mais de piètre qualité, suivis d’itérations où l’équipe corrige les anomalies qui en découlent.

Une fois les problèmes détectés et les causes analysées, l’équipe cherchera des idées afin d’y remédier et mettra en place des actions permettant d’améliorer la productivité. Nous verrons dans la suite de cet article les méthodes permettant de conduire cette réflexion et d’établir les actions à entreprendre.

Pourquoi ne pas se contenter d’appliquer les « bonnes pratiques » ?

Dans le but de rester performant et concurrentiel, pourquoi ne pas se contenter d’un peu de veille et d’appliquer les différentes pratiques reconnues comme efficaces et développées par les experts des méthodologies de développement ?

Premièrement, il existe un nombre très important de bonnes pratiques et il est impossible de toutes les appliquer. De plus, les méthodologies n’étant pas toujours compatibles entre elles, nous nous retrouverions souvent à devoir faire un choix cornéliens entre telle ou telle méthodologie. Enfin, ces méthodologies elles même évoluent en permanence et nous incitent par la même occasion à faire de même, nous plongeant dans une spirale sans fin d’adoption de nouvelles méthodes de travail à appliquer « by the book ».
Une approche plus pragmatique est donc conseillée. Elle consiste à essayer et adapter tout ou une partie de ces méthodes, en réponse à un besoin ou à un problème. Ce dernier point est particulièrement important, les réponses apportées par une méthodologie doivent effectivement découler d’un problème levé par l’équipe de développement. Il n’est donc pas nécessaire d’apporter une réponse (nouvelle méthodologie) s’il n’y a pas de problème.

Deuxièmement, les équipes de développement sont différentes les unes des autres. Les personnes qui les constituent, le contexte du projet, les technologies employées, la culture de l’entreprise etc. sont autant de paramètres à prendre en compte dans le choix d’une méthodologie plutôt qu’une autre. Il est donc impératif que l’adoption d’une méthodologie soit unanime et non imposée. Prenons l’exemple du pair programming, cette méthodologie qui consiste à développer en binôme est assez peu répandue malgré ses vertus. Son adoption est souvent difficile pour plusieurs raisons : incompréhension de la direction, acceptation nécessaire du regard critique de son binôme sur notre manière de développer, adoption d’un rythme différent, etc. Sans un engagement complet de l’équipe, il ne sera pas possible de mettre en œuvre ce genre de méthodologie. Si les membres de l’équipe n’y adhèrent pas, il sera difficile de la mettre en place.

Devant l’opulence des méthodologies et les différences entre les équipes de développement, il est nécessaire de continuellement adapter nos méthodes de travail et d’en expérimenter de nouvelles. C’est précisément le but des rétrospectives, que nous allons étudier dans la suite de ce document.

Le principe « inspecter et adapter »

L’amélioration continue fait appel à la rétrospective comme outil d’analyse et de prise de décision. Elle repose globalement sur les phases suivantes :

• identification des problèmes,
• détermination des causes d’origine ( root cause analysis ),
• définition des actions à entreprendre pour remédier à la cause racine.

Cette méthodologie nécessite une importante dose de courage afin d’aborder les problèmes et leurs causes racines. Il peut en effet être éprouvant d’effectuer cet exercice – qui est malgré tout nécessaire – car si les problèmes de fond ne sont pas abordés, l’équipe est condamnée à ne plus progresser.
Cette constatation rejoint le paradoxe de Stockdale qui peut être défini de la manière suivante :
« Nous devons croire en nos capacités à réussir » et en même temps « être capable de se confronter à la plus brutale des réalités, quelle qu’elle soit ».

La démarche d’amélioration continue nécessite donc que les problèmes ne soient pas « cachés sous le tapis » mais bien au contraire, exposés au grand jour afin de trouver leur origine et les actions à entreprendre afin de les régler.

Les working agreements

Un peu plus tôt dans cet article, nous avons parlé des règles de travail ou working agreements et nous allons maintenant les définir.

Les working agreements sont des valeurs et accords érigés par l’équipe de développement. Ils appartiennent à l’équipe et ont pour rôle de responsabiliser chaque membre. Certains accords définissent des interactions et processus entre les différents acteurs du projet dans le but d’optimiser l’efficacité de l’équipe. Ces working agreements se développent et s’ajustent au fil du temps. Afin que tout le monde les ait en tête, on peut les afficher sur un tableau à la vue de tous.

Voici quelques exemples de valeurs : qualité, simplicité, travail d’équipe, courage. Ou encore quelques exemples de règles: heure et lieu du stand-up meeting, définition d’une* user story “done”, disponibilité du product owner, etc. Il peut être utile, voir nécessaire de définir des workings agrements dans le cadre d’une rétrospective lorsque l’équipe manque de discipline.

Structure d’une rétrospective

La rétrospective fait partie intégrante du cycle de développement. Elle se déroule à la fin de chaque sprint ( ou itération). Au démarrage de la rétrospective, l’animateur définit l’agenda, les enjeux et les objectifs de la rétrospective, et peut être amené à rappeler les working agreements. Le début de la réunion peut aussi être propice pour faire une petite synthèse du dernier sprint et remercier l’équipe pour ses efforts.

Basées sur le principe Inspect and Adapt présenté précedemment, les rétrospectives sont structurées en cinq étapes amenant l’équipe à identifier les problèmes et dysfonctionnements et à trouver des solutions afin d’améliorer le processus de développement. La rétrospective est une réunion timeboxée, la gestion du temps est très importante.
Ci-dessous, vous pouvez observer les cinq étapes d’une rétrospective, ainsi qu’un pourcentage de répartition de chacune sur la durée totale de la réunion:

• définir la réunion (5%) : définir l’agenda, les enjeux et les objectifs de la rétrospective, et rappeler les working agreements si nécessaire,
• collecter les données (30-50%) : créer une vision globale et partagée de tous,
• trouver des idées (20-30%) : identifier les forces et les faiblesses, analyser les causes et trouver des solutions,
• décider des actions à mener (15-20%) : sélectionner quelques actions à mener aux prochains sprints,
• conclure la rétrospective (10%) : dé-briefer sur la réunion, noter les décisions et remercier les participants.

Par ailleurs, il peut être utile de garder du temps (5-10%) en réserve pour se prémunir des débordements.

L’organisation spatiale de la salle de réunion est aussi une donnée à ne pas négliger. En effet, une barrière physique peut rapidement devenir une barrière mentale. Éviter les salles de type « théâtre” et privilégier un espace circulaire ou semi-circulaire pour que tout le monde puisse se voir et communiquer facilement.

Les activités

A chaque étape d’une rétrospective sont associées des activités. Armé de papiers, de crayons, et de post-its, l’équipe travaille et réfléchit dans un cadre ludique et studieux. Selon la taille de l’équipe, et afin de favoriser la participation de tous, des sous-groupes peuvent être formés temporairement pendant la réalisation d’une activité. D’autre part, les activités sont sensées permettre d’apporter de nouvelles perspectives et un cadre pour aider les participants à réfléchir ensemble. Il peut y avoir plusieurs activités par étape.

Les activités sont étudiées pour répondre aux principes ARCS :

• Attention : Garder la concentration des participants,
• Relevant : Pertinent par rapport aux objectifs,
• Competence : Tous les participants peuvent accomplir les tâches,
• Satisfaction : Ne pas avoir le sentiment d’avoir perdu son temps.

Un prochain article présentera de manière plus détaillée chacune des étapes d’une rétrospective, et nous verrons aussi des exemples d’activités.

Les rôles du retrospective leader

L’animateur de la rétrospective (ou retrospective leader) n’est pas nécessairement le Scrum Master. Ce rôle peut tourner entre les différents membres de l’équipe.

Préparer la rétrospective

La première fonction du leader est de préparer la rétrospective. Pour deux heures de réunion, il faut parfois compter la même durée pour la préparation. Il définit alors les activités de la rétrospective en fonction de divers paramètres comme la taille de l’équipe, la complexité du projet, et choisit les activités. Pour se prémunir des débordements durant la réunion, une astuce est de sélectionner en seconde option des activités plus courtes.

Animer le groupe de travail

La seconde fonction du leader est d’animer la réunion. Tout d’abord, il contrôle le temps passé sur chaque activité. Cette tâche peut aussi être déléguée à un autre participant. Par ailleurs, il est le garant des Working Agreements et s’attache à les faire respecter par tous.
Avant de commencer une activité, l’animateur présente son déroulement et rappelle les objectifs de celle-ci (exemple: collecter un ensemble de données réparties sur une période afin d’obtenir une vision partagée par tous). Pendant l’activité, il répond aux questions et observe attentivement le niveau de participation. Il peut aussi être amené à recadrer l’activité en cas de débordement.

Le facilitateur

En tant qu’animateur d’un groupe de travail, le leader a aussi un rôle de facilitateur. Le facilitateur est une personne neutre qui ne prend pas parti, et n’expose pas son point de vue durant la réunion. Il met en place des méthodes pour aider le groupe à travailler efficacement. Pour parvenir à cela, il encourage la participation de tous, favorise la compréhension mutuelle et cultive la notion de responsabilité partagée.

L’art de gérer le « facteur humain »

Les individus d’une équipe en tant qu’êtres humains ont des émotions et sentiments. Les rétrospectives exposent un certain nombre de problèmes d’origines variées. Elles sont parfois sources de tensions et de conflits au sein de l’équipe. Chaque individu étant unique, celui-ci réagira différemment à une situation donnée. La manière de gérer les rapports humains et la communication avec les autres sont des enjeux importants pour que la réunion apporte une réelle valeur à l’équipe et au projet. On comprend alors la nécessité pour l’animateur de faire preuve d’empathie, d’avoir un sens de l’observation, et une certaine maîtrise de soi.
Son rôle consiste alors à désamorcer les tensions et attaques directes, qui n’apportent rien aux problèmes de fond. Il peut aussi amener les individus à exprimer leurs émotions de manière subtile, afin de libérer en eux des ressentiments inexprimés. Par exemple, au lieu d’employer la question directe à un membre: « Qu’as-tu ressenti durant ce dernier sprint ? », utiliser plutôt celle-ci: « Quels sont les moments importants qui t’ont le plus marqué négativement et positivement ? ». Bien sur l’animateur n’est pas responsable des émotions de chacun. Il ne peut pas les contrôler, mais il doit faire en sorte que la réunion reste productive.
Par ailleurs, il peut s’appuyer avec parcimonie sur des méthodes et techniques psychologiques. Sans rentrer dans le détail de cette science, voici deux exemples pour illustrer notre propos.

Le langage Je/Il

Version Il: « Julien n’a pas arrêté de casser le build ! »
Version Je: « J’avais peur que nous rations notre objectif, car nous avons eu beaucoup de build cassés. »
Encourager l’emploie du pronom « Je » plutôt que « Il ». En effet, le « Je » centre le débat sur l’observation et l’expérience de l’intervenant, plutôt que de blâmer une personne. Lorsque quelqu’un critique ou attaque personnellement une autre personne, il faut intervenir et recadrer la discussion sur le contenu, afin de découvrir les causes réelles d’un problème.

Le triangle de Karpman

Le triangle de Karpman représente trois rôles: La victime, le persécuteur, et le sauveteur.
C’est un modèle qui tend à exprimer, que si une personne utilise un de ces rôles (par exemple la victime), elle entraîne l’autre à jouer un rôle complémentaire (le Sauveur ou le Persécuteur). Il peut aider à comprendre les mécanismes ayant généré un conflit. Ainsi, L’animateur avisé pourra éviter de rentrer dans le rôle du sauveteur, chose qui arrive bien souvent quand un membre s’en prend à un autre.

Conclusion

Dans ce premier article, nous avons introduit ce que sont les rétrospectives et leur utilité. Nous avons vu que les rétrospectives s’inscrivent dans une démarche d’amélioration continue. Elles permettent aux équipes et aux membres qui les composent de progresser et de mieux collaborer.
Nous avons aussi vu que les rétrospectives s’articulent autour du principe Inspect and Adapt qui nous force à réaliser une analyse en profondeur des problèmes avant de leur apporter des solutions.

Ces rétrospectives sont animées par un Leader ayant pour rôle de faire en sorte que le temps investi dans la rétrospective soit rentabilisé au mieux (ceci commence par le respect du temps imparti). Le retrospective leader est aussi responsable du choix des activités et du bon déroulement de la séance de travail.

Dans le prochain article, nous détaillerons les différentes phases des rétrospectives et nous vous proposerons quelques activités inspirées du livre d’Esther Derby et de Diana Larsen, Agile Retrospectives: Making Good Teams Great.