Dans les méthodes agiles, la rétrospective est l’activité qui soutient le 12e principe du manifeste agile : à intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. C’est sur la rétrospective que repose l’amélioration continue, critique dans le déploiement de l’agilité. Pourtant, l’expérience montre qu’il s’agit de la pratique agile la plus facilement abandonnée, ou pire, détournée. Plutôt que d’accepter cela comme une fatalité, regardons le problème sous l’angle du Lean.

La bureaucratie agile, un oxymore devenu réalité

Les exemples de rétrospectives vides de sens abondent. J’ai ainsi vu une équipe agile qui, pour gagner du temps sur ce temps qu’elle considérait comme perdu, avait transformé la rétrospective en revue d’un plan d’actions d’amélioration parfaitement creux, et que l’équipe reportait consciencieusement d’itération en itération. Essayez les mots clés sur Google Boring + Retrospective, et vous aurez vite fait de comprendre l’ampleur des dégâts. Or, sans amélioration continue, l’agilité a tôt fait de se transformer en une nouvelle bureaucratie, dont le seul intérêt est de produire un peu moins de paperasse que celle qu’elle a remplacé. Plus grave, la stagnation des pratiques peut conduire l’organisation à remettre en cause sa transformation agile. Et ne parlons pas des dégâts sur l’équipe, qui soit remonte des problèmes qui semblent n’intéresser personne, soit se censure en attendant la fin de cette réunion pensum.

La rétrospective existe sous deux formes. La première est la rétrospective de sprint qui a lieu à chaque fin d’itération, telle décrite par le Scrum Guide. Après 15 ans d’existence, elle se pratique sous un grand nombre de variantes, plus ou moins « gamifiées », et souvent avec l’aide d’un coach externe à l’équipe. La rétrospective de jalon, qui a lieu à la fin du projet, est la version agile des anciennes post-mortems qui se pratiquaient à couteaux tirés et voyaient souvent le sang couler. Utiliser des post-it à la place des PowerPoints n’a pas vaincu les réticences des équipes, et cette variante de la rétrospective est par conséquent la plus rare. Nous concentrerons donc nos efforts sur la première : si l’équipe arrive à (re)mettre en place des rétrospectives à chaque sprint, elle n’aura pas de mal à le faire à la fin du projet – alors que l’inverse n’est pas forcément vrai.

Il existe plusieurs raisons à la déshérence des rétrospectives. Une lecture sociologique serait de dire que le projet, proposé par l’organisation à partir de la vision managériale, s’appuie sur une pensée rationnelle et utopiste, au sens propre du terme : elle essaie de créer un modèle meilleur (la définition de « meilleur » pouvant fortement varier). Comme tout modèle utopique, le projet ne résiste pas à l’immersion dans la réalité, et en est fortement altéré. Il y a des amendements, des dérives, des compromis, et le résultat final est forcément différent de ce qui avait été planifié. Faire une rétrospective, c’est forcément confronter la vision managériale avec la réalisation, et les biais cognitifs sur lesquels reposent la volonté planificatrice du management n’y survivraient pas. Mais tout bon coach agile – qu’il ait lu cet éclairant article de Jean-Luc Metzger ou non – est conscient de ce problème et ne permettrait pas, quitte à y laisser sa vie, au management intermédiaire de participer à la rétrospective.

Pour intéressante que soit cette analyse – comme l’est également celle selon laquelle le projet serait par essence anhistorique et résolument tourné vers le futur (une idée que l’on trouvera chez Jean-Luc Boutinet, dans son Que Sais-Je)  – nous lui préférons l’explication vérifiée sur de nombreux terrains, selon laquelle les équipes ne pratiquent pas les rétrospectives car elles n’y trouvent tout simplement pas d’utilité.

Pourquoi n’y trouvent-elles pas d’utilité ? Parce qu’elles ne savent pas, ou ont oublié, que Scrum est inspiré du Toyota Production System, comme Jeff Sutherland l’a expliqué lors du Lean IT Summit 2014, et qu’il se veut comme tel une démarche d’apprentissage et non une incarnation un peu plus fun du taylorisme.

Le PDCA en rétrospective, pour démarrer un voyage Lean

C’est cette parenté qui permet de redonner avec le Lean un sens aux rétrospectives : si la rétrospective est la version agile de l’amélioration continue, autant aller jusqu’au bout de la démarche et adopter dans le modèle de Toyota les pratiques en lien avec ce principe. Le PDCA, surtout, par son approche structurée et méthodique, s’y prête particulièrement bien. Le point de départ de la boucle d’apprentissage du PDCA est un écart de performance, et à moins d’être dans l’improbable situation où l’équipe a déployé toutes les stories planifiées du sprint sans aucun problème de qualité, celui-ci est facile à caractériser.

En emmenant l’équipe dans la boucle du PDCA, non seulement vous redonnez du sens aux rétrospectives en les amenant à se poser la question de ce qu’ils ont appris du sprint, mais vous vous prémunissez de toutes les dérives des post-mortems dont nous parlions plus haut : la recherche de fautifs, les attaques personnelles, l’évitement…

En engageant de cette manière l’apprentissage à partir des écarts, vous introduirez ainsi une culture de la résolution de problèmes qui vous permettra de mêler le management aux rétrospectives, une chose qui vous paraissait inconcevable dans le cadre de l’agilité et qui est pourtant tellement importante dans le Toyota Way.