Rétrospectives manquées

La conférence Agile France 2010 mettait la rétrospective à l’honneur en incluant les cartes des alchimistes agiles dans le sac de bienvenue. En dépit de tout ce qu’elle apporte, il faut veiller à ne pas l’idéaliser car elle aussi peut bogguer.

Je vous propose de faire un tour sur quelques problèmes classiques.

Les actions ne sont jamais faites / Les rétrospectives ne servent à rien.

A chaque itération, l’équipe réfléchit et propose des solutions aux problèmes rencontrés. Et à chaque itération, aucune action n’est faite. Cela revient à brasser du vent : c’est bien de se poser des questions, de voir les problèmes mais s’il n’y a jamais de concrétisation, autant ne pas en faire, tout le monde perd son temps. C’est aussi de plus en plus frustrant. Pour ne pas tomber dans ce schéma, il vaut mieux limiter le nombre d’actions prises, voire déjà en réaliser une seule. Il ne sera pas trop tard pour en rajouter d’autres si vraiment, l’équipe est au chômage technique (mais j’en doute…). Demandez-vous aussi peut-être si vous souhaitez réellement résoudre les problèmes ou juste réunir l’équipe pour se plaindre pendant une heure. Cela peut avoir une utilité exutoire, mais c’est moins constructif. Proposez vingt actions et n’en concrétiser aucune peut effectivement donner l’impression d’accomplir beaucoup.

Je ne me rappelle plus ce qui s’est passé pendant l’itération.

Il s’agit du syndrome de la page blanche, heu du post-it jaune. Peut-être qu’il n’y a rien à dire mais souvent, si, et c’est dommage de ne s’en rappeler qu’après coup.

Les entretiens préalables peuvent inciter les interlocuteurs à réfléchir en avance à ce qui s’est passé.

J’aime bien aussi afficher les post-its des users stories du task-board pendant la réunion pour nous rafraichir la mémoire. Le scrum master pourrait en complément récapituler les stories du sprint avant de commencer la réunion.

Une autre alternative pourrait être de noter au fur et à mesure de l’itération les points que l’on souhaite aborder sur une feuille. C’est ce que je fais lorsque j’ai un point à aborder au standup du lendemain, pour ne pas l’oublier. Par contre dans ce cas, nous pouvons nous demander pourquoi attendre la rétrospective si le point peut être abordé voire traité dès le lendemain. Parfois, ce ne sera effectivement plus la peine d’en parler en rétrospective. D’autres fois, l’intérêt sera maintenu si l’obstacle est toujours présent ou si l’on souhaite se faire entendre encore un peu plus (nous sommes à priori un peu plus attentifs en rétrospective).

Le même problème apparait plein de fois mais n’est jamais choisi pour être traité.

Cela peut signifier que vous êtes le seul à subir ce problème et/ou que les autres ne le voient pas. Essayez de le rendre plus visible à chaque fois qu’il apparait, tirer les autres vers vous quand vous devez le traiter.

Si vous utilisez un système de votes par jeton (très recommandé), c’est le moment de mettre tous vos jetons sur ce sujet.

La rétrospective ne sert à rien car les problèmes que nous rencontrons ont des causes externes.

Effectivement, en discuter pendant une heure ne sert à rien si les personnes présentes n’ont aucune action possible dessus.

La question suivante est : est ce que des personnes présentes ont une influence sur ces personnes, pour les inciter à venir? Si elles viennent, il faudra exclusivement traiter ce sujet pour qu’ils ne perçoivent pas la rétrospective comme une perte de temps.

Par ailleurs, nous pouvons aussi nous demander si ce problème insolvable n’est pas un bouc émissaire. Est ce qu’à part ça, si ce problème était résolu, nous pourrions qualifier le projet de parfait ? N’y a t-il aucun gaspillage, aucun temps d’attente, aucune frustration, tout est toujours incroyablement facile et plaisant à faire ? Une variante est :

La rétrospective ne nous sert pas car nous traitons les problèmes dès qu’ils apparaissent.

Déjà, bravo, vous êtes forts ! Votre équipe est incroyablement mature, communique sans problème, est super efficace et aucune contrainte extérieure ne vous embête, la vie est belle !

C’est bien mais c’est peut-être aussi que vous ne voyez pas les problèmes. Est ce qu’individuellement, chacun pense réellement la même chose ?

Deuxièmement, cette approche nous laisse passer à côté d‘améliorations de fond, sur des problèmes que l’on voit moins ou qui ont fondu dans le décor. La réunion pourra acter sur une demi-journée à débloquer pour enfin tester un nouveau système de version par exemple.

Les rétrospectives sont monotones.

Si les rétrospectives ont toujours le même format, nous pouvons finir par ne plus voir les problèmes et s’engourdir. Nous pouvons revitaliser cela en variant les exercices ou en en inventant d’autres.

Elle peut respecter le format type la plupart du temps : Accueil, Donnees, Actions, Au revoir, maisaussi digresser. L’essentiel étant qu’elle permette de donner du recul sur notre quotidien. Vous pouvez vous baser sur le burn down chart ou autres métriques, ou partir sur les users stories non terminées. Elle pourrait aussi parfois prendre la forme de jeux, d’ateliers de lecture, de débat sur un article (“est ce que l’équipe ne commence réellement à travailler qu’après le standup?”), si un besoin de changer se fait sentir ou si elle devient une contrainte.