Rétrospective : arrêtez la ou rénover la de fond en comble.

Invitation : si vous êtes un coach agile, prenez un stylo et noter la réponse à la question “qu’accompagnez-vous à travers la rétrospective ?” avant de lire cet article.

Je suis sidéré de constater que dans tant d’organisations que les rétrospectives apportent si peu à leurs participants qu’ils en viennent à raison à les abandonner après plusieurs mois de pratique. Il est grand temps que les facilitateurs agiles comme les coaches agiles eux-mêmes réfléchissent à ce qu’ils doivent accompagner à travers cette pratique. Je suis effaré de voir l’absence de compréhension profonde de cette pratique par les coaches agiles eux-mêmes. Sans nul doute, ces derniers accompagnent très bien la forme, c’est à dire transmettre comment animer une rétrospective. Mais ils sont complètement aveugles sur le fond, ou à minima ne l’accompagne pas en conscience, ce qui est un vrai problème pour l’Agilité.

Chères équipes, vous avez raison d’arrêter ce qui ne vous semble pas utile. C’est à vos accompagnants de vous montrer le chemin, c’est d’eux que vient le problème s’ils ne comprennent pas ce qu’ils doivent accompagner.

Aller, ça va piquer, tenez-vous bien.

Quel comportement cherchons-nous à renforcer à travers la rétrospective ?

La rétrospective est une façon d’apprendre à l’équipe à résoudre ses problèmes. Pas à passer un bon moment ensemble. Pas à permettre à l’équipe d’avoir au moins un lieu d’échange pour parler vrai. Pas à réduire la dette émotionnelle. Pas à innover. Pas à partager ses plaintes et obtenir un peu d’écoute. Pas à revenir sur des soucis que l’on a eu au cours de la période précédente. Dès lors que l’on tort l’objectif premier des pratiques agiles, on dénature leur sens et l’équipe n’y comprend alors plus grand chose.

Non, je le redis, la rétrospective cherche à apprendre à l’équipe la résolution de problèmes. Tout le reste est secondaire voire inutile car il détournera votre attention.

C’est parce que l’équipe constatera qu’elle parvient à régler ses problèmes qu’elle deviendra convaincue de l’intérêt de cette nouvelle pratique qu’est la rétrospective.

Tant d’équipes arrêtent la rétrospective parce qu’elles ne sont pas convaincues de son bénéfice. Tant d’équipes continuent également pour éviter les blâmes de l’organisation et font alors de la rétrospective une coquille vide de sens.

Oh, je vous vois venir… Est-ce qu’après tout, tout peut être considéré comme un problème ? Absolument pas, et pour plusieurs raisons d’ailleurs.

Le problème du problème

Pour apprendre à une équipe la résolution du problème, il faudra d’abord être vigilant sur les mots eux-mêmes. Les confusions suivantes apparaîtront au cours de cet apprentissage :

• Nous confondons souvent nos soucis et nos problèmes.
  Les sujets d’échange des rétrospectives portent alors très souvent sur les soucis de l’équipe, sans qu’elle n’arrive à identifier réellement ses problèmes.
• Nous confondons systématiquement symptômes et problèmes.
  Les plans d’actions issues des rétrospectives sont fréquemment des pansements. La triste conséquence est que bien que l’équipe se mobilise sur ces plans d’actions, ils ne changeront pas grand-chose.
• A tout qualifier de problème, nous ne nous focalisons par sur ceux qui devraient nous importer.
  Disons que l’équipe est parvenue à passer outre le piège du souci et le piège du symptôme. Elle a identifié au bout d’un moment une dizaine de “problèmes”. Tous sont-ils importants pour l’organisation, pour les clients, pour l’équipe ? Le fameux “arriver à l’heure en meeting”, si tant est que ce soit une cause racine d’un problème qu’elle a analysé, va-t-il changer pour du mieux ?

Pas de problèmes sans objectifs de performance

Il faut ici nous appuyer sur la définition Lean de ce qu’est un problème :

Un problème est un écart de performance.

Cette définition est essentielle car c’est grâce à elle que nous allons pouvoir définir notre problème précisément, évaluer l’efficacité des solutions que nous allons mettre en place, et affirmer que le problème a été résolu.

Oh pas de chance, l’équipe n’a pas d’objectif de performance… plusieurs options s’offrent à vous :

1. L’équipe est indépendante sans accès à ses parties prenantes ; elle doit d’abord définir ses objectifs de performance pour se mettre en capacité de s’améliorer.
2. L’équipe est auto-gérée ; elle doit aller chercher son manager pour lui faire expliciter ses exigences vis-à-vis d’elle (autrement dit, manager son manager s’il n’est pas au rendez-vous de vous communiquer ses exigences tout seul).
3. L’équipe est autonome et pro-active ; elle doit récupérer et interpréter les exigences de ses parties prenantes, et chercher à s’aligner sur la stratégie de l’organisation pour définir ses objectifs de performance.

Pas de problèmes sans définition de la notion de performance

La performance c’est quoi ?

Le problème du mot performance est qu’il a longtemps servi à un management du “command and control” pour presser les femmes et les hommes de l’organisation. Il est nécessaire de se réapproprier la notion de performance comme un élément positif qui permet le développement des individus dans l’organisation.

La performance est un niveau de résultat que l’on désire. Mais que désire l’équipe, les clients, l’organisation ? La réponse est évidemment contextuelle. J’observe notamment les scénarii suivants :

• La direction et les managers veulent de la Qualité mais n’en définissent pas de seuil à atteindre. L’équipe ne saura pas si elle est en dessous ou au-dessus du niveau attendu.
• Les objectifs de performance sont imposés aux équipes sans en discuter avec elles et ceux-ci s’accompagnent trop souvent par un manque de moyen. La rupture de motivation voire de santé de l’équipe ne vient rarement d’une exigence trop élevée, mais de l’association entre une exigence élevée avec une absence de moyens et de support apportés à l’équipe.
• Les Métiers veulent souvent que les équipes informatiques traitent leurs demandes plutôt que que de trouver des solutions à leurs besoins. L’équipe informatique qui n’aura pas bien réfléchi à ce paradoxe définira maladroitement l’objectif de performance ” faire ce qu’on leur dit de faire”. Vous pourrez vous améliorer à partir de cet objectif sans pour autant être convaincu du bénéfice de la rétrospective. Ce sera comme souvent la faute à l’Agilité, coupable facile, plutôt que la faute à un manque de réflexion.
• Les seuils de performance définis sont souvent binaires : soit une attente de médiocrité vis-à-vis de l’équipe, soit une performance impossible à atteindre. Les deux sont sources de démotivation importante. La flemme managériale poussera également à définir un seuil élevé long terme, pour éviter un accompagnement plus incrémental du niveau d’exigence qui a la vertu d’offrir des petites victoires intermédiaires.

Avec mon équipe actuelle de coaches agiles dont je suis le manager, nous désirons notamment avoir une super dynamique pour devenir une équipe performante. Comme quoi, mesdames messieurs, l’aspect RH peut être intégré à la notion de performance.

Je vous rapporte les propos (reformulées) de ma mentor lorsque j’évoquais avec elle la notion d’exigence lors de ma mise en situation pour passer manager :

Porter une exigence forte vis-à-vis d’un collaborateur est un signe de respect car on le considère capable d’atteindre ce niveau de résultat. Les managers qui ne fixent pas d’exigence élevée se préoccupent assez peu du développement des collaborateurs qu’ils encadrent.

La grande rénovation… de la rétrospective

La rétrospective est un très mauvais nom je trouve. Elle décrit ce que l’on fait – exposer l’évolution passée – plutôt que ce que l’on cherche à faire – résoudre nos problèmes -.

Je choisi désormais de parler de résolution de problèmes aux équipes que j’accompagne plutôt que de la rétrospective elle-même et de ses nombreux formats.

Il est temps que le Lean, le vrai Lean, inspire un peu plus nos accompagnements agiles, ne pensez-vous pas ?