La rétro qui ne sert (presque) à rien

En changeant de projet et donc d’équipe, j’ai animé une rétrospective d’entrée afin de me faire un avis sur ce qui préoccupait l’équipe et identifier des pistes d’amélioration.

L’équipe travaillait ensemble depuis près d’un an et j’avais eu l’information que beaucoup de choses n’allaient pas.

J’ai choisi de faire une rétrospective classique : tout le monde expose les points positifs et négatifs qu’il a pu identifier lors de la dernière release, ensuite on catégorise les points collectivement et on essaye d’y apporter des solutions sous forme d’actions d’amélioration.

J’ai pendant la rétrospective été confronté à un gros problème que je n’ai su régler qu’à posteriori: l’équipe me remontait des problèmes sur des solutions déjà mise en place sans pouvoir me dire pourquoi elles avaient été mise en place. Je m’explique.

Par exemple, « Ne plus accepter les changements le lendemain du GO ou de l’écriture des US » ou encore « Arrêter de répondre à toutes les questions du client » sans se demander pourquoi le client posait autant de question ou sans savoir réellement pourquoi ils devaient faire autant de merge request…

Au total l’équipe a remonté une cinquantaine de points positifs ou négatifs, la plupart sous forme de solutions déjà réfléchies.

J’ai passé du temps à faire les 5 pourquoi pour trouver la cause racine mais l’équipe était trop « dans le jus » et je me suis retrouvé démuni pour les amener à me faire comprendre ce qui les avait poussé à cette situation. A la fin du temps prévu pour la rétrospective aucune action n’avait vraiment émergé. C’était donc, à mes yeux, un échec. Je n’aime pas rester sur un échec si je n’en tire pas quelque chose (win or learn)…

Ce n’est qu’assez récemment en visionnant « l’Art de la rétrospective » d’Alexandre Boutin que j’ai compris avoir mené une rétro « purge » : tout le monde en a gros sur la patate et cherche à vider son sac sans réellement chercher à comprendre pourquoi la situation est celle-ci ni chercher à trouver une solution. J’aurai du beaucoup plus cadrer les choses : à commencer par limiter le nombre de post-it par personne pour dégager du temps en fin de rétro et se concentrer sur des solutions sur moins de sujet. On ne monte un escalier que marche après marche.

Concernant les 5 pourquoi qui n’avaient pas fonctionné (on tombait sur de la recherche de coupable plutôt que de cause racine), il m’aurait fallu poser la question de manière plus positive du point de vu de celui qui émet le problème.

Plutôt que de demander : pourquoi voulez vous refuser le changement de périmètre? (parce que ça nous « embête » de refaire)

J’aurai du demander : Et si nous refusons les changements qu’est-ce que cela apporterait? (on n’aurait plus de boulot… donc ce n’est pas le vrai problème… le problème c’est pourquoi le client n’est pas en mesure d’exprimer son besoin du premier coup… a-t-il besoin d’accompagnement?…)

Grâce à cette formulation on ne reste plus bloqué sur le problème mais on se projette après la résolution. On se force à prendre un peu de recul.

 

 

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s