Press "Enter" to skip to content

Associer des KPI aux actions de Rétrospective

Que faire lorsque la Rétrospective est vue comme du “temps perdu en réunion” ?

Le but même de l’amélioration continue est de permettre de travailler mieux et plus vite.

Cependant, en présence d’une amélioration continue déficiente, les personnes deviennent réticentes à y consacrer du temps car vu comme du “temps perdu en réunion.” Difficile de les contredire dès lors que les actions définies sont rarement mises en place, ou rarement utiles.

Associer des KPI aux actions de Rétrospective

Un calcul du retour sur investissement (ROI) des actions peut être mis en place. Il faut alors définir clairement pour chaque action quels indicateurs doivent être surveillés pour juger de la réussite de l’action.

Attention à bien faire la différence entre indicateurs qui montrent que l’action a été mise en place, et indicateurs qui montrent que l’action a bien eu l’effet escompté sur le système. Les deux sont intéressants :

  • Le premier pour confirmer que l’action a bien été mise en place, que le système de suivi des actions fonctionne
  • Le second pour confirmer que la méthode intellectuelle utilisée pour définir les actions a bien menée à définir des bonnes actions qui améliorent effectivement le système — dit autrement, que l’action a bien l’impact attendu ou du moins qu’elle a un impact positif sur la situation

Exemple d’action et d’indicateurs

Partant du constat que les éléments de travail restent souvent bloqués durant la phase de revue de code, (Code Review) l’équipe décide de mettre en place le bînomage ou Pair-Programming.

Indicateur de mise en place : mise en place d’une matrice de pair-programming, qui permet de voir qui fait du pair-programming avec qui dans l’équipe. À chaque fois qu’une session de pair-programming a lieu, on met une croix ou un bâton dans la case qui correspond aux deux personnes en question. On pourra donc facilement vérifier en fin de Sprint si l’action a bien été mise en place, en l’occurrence si l’équipe a bien mis en place le pair-programming.

Le but de ce premier indicateur est bien d’éviter des actions floues, non mesurables ou non actionnables, comme “être plus rigoureux” ou “communiquer mieux.” En cascade, cet indicateur a l’effet de bord positif de forcer l’action à être mise en place : dans cet exemple, le fait de mesurer les sessions de pair-programming rappellera à tout le monde de faire ces sessions de pair-programming.

Indicateur de réussite : spontanément, on imaginerait suivre le temps passé dans chaque étape du flux de travail, a minima le temps passé dans la phase de revue de code. Attention, cet indicateur risquerait de rater la véritable cible de l’action de rétrospective. En réalité, ce n’est pas le temps passé en revue de code qui nous intéresse, mais le délai total que met un élément de travail à être terminé. C’est donc bien le temps nécessaire pour parcourir l’ensemble du flux de travail qui nous intéresse.

Le temps passé spécifiquement en phase de revue de code peut être intéressant en tant qu’indicateur secondaire, mais ce serait une erreur de s’en contenter :

  • Il suffirait “d’oublier” de déplacer un élément de travail pour réduire le temps passé en phase de revue de code.
  • Admettons que, comme prévu, la mise en place du pair-programming réduise drastiquement le temps passé en phase de revue de code. Mais est-ce que pour autant le système fonctionne mieux ? Et si on a juste reporté ce temps dans une autre phase, est-ce qu’on y gagne ?

Ce deuxième indicateur rappelle l’importance d’avoir bien analysé la situation et de ne pas simplement agir sur les symptômes. Il faut en permanence prendre du recul et se focaliser sur ce qui compte réellement.

Exemple de board de suivi

Les actions peuvent ensuite être suivies dans un board dédié. Ces indicateurs peuvent être définis formellement ou informellement. Voici un exemple de board de suivi d’actions de rétrospective, ou Kaizen Board, d’une équipe très mature :

https://www.youtube.com/watch?v=3LRTBgd373w&feature=youtu.be&t=19

Suivi en Sprint Review

À noter, il est aussi possible d’envisager de faire le point sur les actions de rétrospective pendant la Sprint Review, en présence des parties prenantes. Celles-ci sont souvent très intéressées de connaître quelles actions met en place l’équipe dans sa démarche d’amélioration continue.

C’est également logique d’en parler à ce moment-là puisque les actions de rétrospective font partie du backlog de Sprint, sur lequel on aura fait le point pendant la Sprint Review.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Top