La rétrospective est devenue un rituel incontournable en gestion de projet agile, mais la question de savoir qui y participe reste étonnamment controversée. Faut-il inclure le sponsor, le client, le responsable hiérarchique? La réponse dépend moins des bonnes pratiques théoriques que de la culture de confiance au sein de l’équipe.
Ce que la rétrospective cherche à produire
Avant de débattre de la liste des participants, il est utile de rappeler l’objectif d’une rétrospective (ou retour d’expérience, bilan d’étape): identifier ce qui fonctionne bien, ce qui pose problème et les actions concrètes d’amélioration pour la période suivante. Le Scrum Guide définit la rétrospective comme un moment d’inspection et d’adaptation pour l’équipe elle-même, distinct de la revue de sprint qui porte sur le produit.
Ce principe s’applique au-delà de Scrum. Tout projet bénéficie de moments réguliers où l’équipe examine son propre fonctionnement: processus, collaboration, communication, outils. La fréquence varie (toutes les deux semaines en Scrum, à chaque jalon en mode prédictif), mais le mécanisme est le même.
Le dilemme de la hiérarchie dans la salle
Le problème survient quand un participant a une autorité hiérarchique sur d’autres membres de l’équipe. Un développeur hésitera à mentionner un problème de communication si la personne responsable est aussi celle qui évalue sa performance annuelle. Un chef d’équipe gardera pour lui ses doutes sur la direction du projet si le sponsor est assis à la même table.
Ce n’est pas de la lâcheté: c’est un comportement rationnel. Les recherches en psychologie organisationnelle montrent que la présence d’une figure d’autorité réduit significativement la diversité des opinions exprimées dans un groupe. Amy Edmondson, professeure à Harvard, a formalisé ce concept sous le terme de “sécurité psychologique” (psychological safety): la conviction partagée que l’équipe est un espace sûr pour prendre des risques interpersonnels.
Inclure ou exclure: les deux comportent des risques
L’exclusion systématique de certains acteurs (client, sponsor, manager) crée un problème différent mais tout aussi réel: elle instaure une dynamique “eux contre nous” qui fragmente l’équipe projet. Les décisions d’amélioration prises sans les personnes concernées ont peu de chances d’être mises en oeuvre, surtout quand elles impliquent des changements organisationnels.
À l’inverse, l’inclusion automatique de tous les acteurs transforme la rétrospective en exercice diplomatique où personne ne dit rien de substantiel. Le bilan devient une formalité polie qui ne produit aucune amélioration réelle.
La solution ne réside pas dans la composition de la liste des participants, mais dans la qualité de la confiance au sein du groupe. Une observation de praticien résume bien la situation: les meilleures équipes et les pires équipes ont souvent exactement la même composition de participants aux rétrospectives. Ce qui les distingue, c’est le niveau de confiance entre les personnes présentes.
Techniques pour libérer la parole
Quand la confiance n’est pas encore établie (équipe nouvelle, contexte hiérarchique fort, historique de blâme), plusieurs techniques permettent de contourner les freins à l’expression.
L’écriture individuelle avant la discussion collective est la plus simple et la plus efficace. Chaque participant note ses observations sur des post-its ou dans un document partagé avant toute discussion orale. Cela réduit l’effet de conformité, c’est-à-dire la tendance à aligner son opinion sur celle du premier intervenant ou de la personne la plus senior.
Le format “Start/Stop/Continue” structure la discussion autour de trois questions: qu’est-ce que l’équipe devrait commencer à faire, arrêter de faire et continuer à faire? Ce cadrage factuel limite les dérives émotionnelles et les attaques personnelles.
L’animation par un tiers neutre (facilitateur externe, Scrum Master, collègue d’une autre équipe) modifie la dynamique de pouvoir dans la salle. Le facilitateur peut poser des questions directes que les participants n’oseraient pas formuler et garantir que chaque voix est entendue.
Le retour d’expérience en mode prédictif
Les projets menés en approche prédictive (cascade, cycle en V) pratiquent traditionnellement le retour d’expérience (lessons learned) en fin de projet ou de phase. Le format diffère de la rétrospective agile, mais les enjeux de participation sont identiques.
Le piège spécifique au retour d’expérience de fin de projet est qu’il arrive trop tard pour influencer le projet en cours. Les participants sont déjà passés à autre chose, les souvenirs sont vagues et la motivation pour identifier des améliorations est faible puisqu’elles ne profiteront qu’aux projets futurs.
La bonne pratique consiste à organiser des bilans intermédiaires à chaque jalon significatif, sans attendre la clôture du projet. Ces bilans de jalon (ou rétrospectives de phase) permettent d’ajuster le fonctionnement de l’équipe pendant que le projet est encore en cours et que les participants sont encore engagés.
La confiance comme prérequis, pas comme résultat
Il serait tentant de penser que les rétrospectives construisent la confiance. C’est en partie vrai, mais uniquement si les premières sessions sont suffisamment sûres pour que les participants osent s’exprimer. La confiance est davantage un prérequis qu’un résultat: une rétrospective menée dans un climat de méfiance renforce la méfiance, pas la confiance.
Le rôle du chef de projet ou du Scrum Master est de créer les conditions initiales de sécurité: garantir la confidentialité des échanges, s’engager personnellement à ne pas utiliser les retours contre leurs auteurs et montrer l’exemple en reconnaissant ses propres erreurs. Le premier manager qui dit “je me suis trompé sur ce point” dans une rétrospective change la dynamique pour toute l’équipe.