Aujourd’hui, je vais vous parler des mauvaises pratiques en rétrospective.
Je ne vais pas revenir sur ce qu’est une rétrospective et comment en tenir une, mais je vais vous expliquer ce qu’il faut éviter et pourquoi.
Je me suis surtout inspiré des conseils d’Esther Derby http://www.estherderby.com/2010/06/seven-ways-to-revitalize-your-sprint-retrospectives.html pour vous montrer ce qu’il ne faut pas faire (oui, je ne suis pas d’accord avec elle !).
Introduction
J’ai travaillé longtemps dans le jeu vidéo, et dans les années 90, le magazine Gamasutra proposait une rubrique très intéressante appelée « Post-Mortem« : http://www.gamasutra.com/features/postmortem/
Un Post-Mortem, c’est l’analyse à froid des leçons chèrement apprises lors d’un projet informatique.
La rétrospective, c’est une analyse à chaud, c’est à dire en cours de projet.
Il faut bien comprendre le but premier d’une rétrospective:
apprendre les leçons en cours de projet
Il est impossible de ne jamais faire d’erreur.
L’anecdote la plus marquante que je connaisse est à propos de Hubble (la NASA a des tas d’histoires passionnantes de management):
http://www.techworld.com.au/article/420036/what_went_wrong_hubble_space_telescope_what_managers_can_learn_from_it_/
Lors du déploiement de Hubble, les ingénieurs se sont aperçus que l’optique ne fonctionnait pas:
« A good friend of Pellerin who worked on the telescope fell ill in the wake of the launch and died. »
en français:
« un bon ami de Pellerin qui travaillait sur le téléscope est tombé malade à la suite du lancement et est mort ».
La NASA a bien compris qu’un process est fragile si on essaye de planifier toutes les possibilités.
Un process robuste suppose que quelque chose d’imprévu va arriver, et va chercher à s’assurer que des ressources adéquates sont disponibles pour résoudre le problème.
La rétrospective est là pour apprendre à l’équipe à réagir en cas de problème.
Catégoriser ce qui est arrivé
Beaucoup de personnes recommandent de faire plusieurs listes et de mettre ce qui a bien fonctionné, ce qui n’a pas bien fonctionné, ce qui pose des questions et ce qui requiert notre attention.
Je vous recommande de ne pas faire cela, pour plusieurs raisons:
- personne ne doit juger ce qui a été positif ou négatif lors d’une itération: on n’est pas là pour juger ! Il faut bien comprendre que tout peut servir de leçon. Rien n’est jamais noir ou blanc, en fait tout serait plutôt en différentes teintes de gris: gris foncé à gris clair. Juger que quelque chose est négatif va culpabiliser ceux qui ont travaillé dessus.
Si je veux une équipe efficace, je veux qu’elle puisse résoudre ses problèmes sans qu’il y ait une chasse aux sorcières. - quand on fait plusieurs listes, on se sent obligé de les aborder, même si elles n’ont pas d’importance pour l’équipe.
En général, lors d’une rétrospective, on a le temps de n’aborder que les problèmes immédiats, soit un ou deux sujets seulement.
Changer le format de la rétrospective à chaque fois
Si vous sentez que l’équipe perd l’intérêt des rétrospectives, ne cherchez pas à changer le format !
Changer le format correspond à changer le contenant, alors que le problème se situe probablement au niveau du contenu.
La rétrospective est un rituel du groupe, et il faut que les participants se sentent bien dans l’exercice, qu’ils sentent que la rétrospective est le seul moment où ils peuvent aborder les vrais problèmes du groupe.
En tant qu’animateur, changer le format fréquemment vous fait probablement plaisir, mais cela montre au groupe que vous cherchez plus à vous amuser qu’à aborder leurs problèmes.
Si vous sentez que le groupe ne s’intéresse plus aux rétrospectives, voici quelques hypothèses:
- les participants sentent que ça ne sert à rien, parce que les problèmes réels ne sont pas abordés. Il y a probablement un problème de manque de confiance dans le groupe. Il peut venir du facilitateur, ou d’une personne qui a trop de poids dans le groupe.
- il n’y a peut-être pas de problème important. Ralentissez le rythme des rétrospectives, mais maintenez-les régulièrement (les bonnes habitudes prennent du temps à se mettre en place, les mauvaises s’installent rapidement).
Décider quoi faire
Je recommande de ne pas forcer les décisions lors d’une rétrospective, pour plusieurs raisons:
- pour éviter le syndrome des solutions foireuses instantanées: quand j’ai un problème et que je dois fournir la solution en temps limité, je suis certain que ma solution sera pourrie. Après une bonne nuit de sommeil, la solution est en général bien plus élégante.
- pour éviter que les participants ne défendent leur solution foireuse: tout le monde est toujours fier de proposer une solution, et va chercher à la défendre même si elle n’est pas bonne. Une bonne solution est souvent la combinaison de plusieurs solutions incomplètes.
- pour se focaliser sur le problème plutôt que la solution. Moins je creuse le problème, et moins la solution sera correcte. Si je me focalise sur la solution, les participants sentent que je me fous de leur problème, et que j’essaye de passer à la suite le plus rapidement possible: au suivant !
Attention: lors des premières rétrospectives, je conseille quand même de forcer le groupe à prendre des décisions, afin que chacun comprenne bien pourquoi on est là. Mais après un certain nombre de rétrospectives (en général quand on commence à ne plus avoir de problème de processus), je recommande de ne pas forcer de décision.
Faire tourner les rôles
L’idée semble intéressante mais elle se heurte à plusieurs problèmes:
- certains animateurs n’arrivent pas à rester neutres: ils se focalisent sur leurs centres d’intérêt ou participent à la rétrospective. Le rôle d’un facilitateur est de n’intervenir que si le groupe en a besoin, pas de décider à la place du groupe.
- le rôle du facilitateur est banalisé: le groupe sent intuitivement que le facilitateur représente une certaine autorité morale. Si cette autorité morale est distribuée dans le groupe, elle perd de sa valeur, et le facilitateur aura plus de difficulté pour « tenir » le groupe.
Utiliser les Core Protocols
Les Core Protocols ont été inventés pour éviter les conflits humains, mais le conflit est quelque chose de sain dans un groupe (dans un couple, le conflit indique qu’il y a toujours de l’amour, il n’y a plus d’amour quand l’indifférence s’est installée).
Un groupe qui fonctionne bien n’implique pas que tout le monde est d’accord, mais que la voix de chacun est écoutée.
Halte à la pensée unique !
Vouloir éviter à tout prix le conflit fait en sorte que la confiance ne monte pas dans le groupe, et la frustration s’installe.
Conclusion
Un projet informatique est toujours une aventure humaine.
La rétrospective est le meilleur moment pour créer le lien entre les membres de l’équipe, sans notion de hiérarchie.
Le but d’une rétrospective est de faire en sorte que chaque participant devienne plus mature, plus responsable.
J’espère avoir remis en cause quelques-unes de vos pratiques.
Je referai un article sur les rétrospectives pour expliquer les bonnes pratiques dans quelques semaines.