Au fait, faut que je te fasse un feedback …

La scène se passe dans le métro parisien.

- Tu prends la ligne 9 toi aussi ? Alors comment ça se passe sur ton projet en ce moment ?

- Ca avance … Tiens, faut que je te raconte, nous avons commencé de travailler avec des méthodes agiles !

- J’ai fait la même chose il y a un an et demi … Vous devez être en plein changement alors ! Où en êtes vous, toi et ton équipe, dans ces changements ?

- Nous sommes accompagnés par un consultant, il a commencé à nous parler de feedback, je n’ai pas bien compris où il voulait en venir …

- Que sais-tu du feedback ?

- Je me souviens des définitions qui m’ont été présentées il y a quelques années en formation. On y parlait de cybernétique et d’approche systémique.

- C’est un bon point de départ. Souhaites-tu que je te rappelle comment est présenté le feedback dans les méthodes agiles ?

- Oui.

- Le feedback est l’une des valeurs d’eXtreme Programming. Nous prenons en considération chaque engagement d’itération afin de délivrer un logiciel qui fonctionne. En regard des résultats, nous pourrons adapter le processus afin d’en obtenir de meilleurs. Outre cet éclairage sur les valeurs de la méthode, peux-tu me dire pour quelle raison ton consultant insiste sur les feedbacks ?

- Ca fait cinq itérations que l’on a des problèmes de bugs et le consultant me parle de soigner mes feedbacks ainsi que ma communication alors que j’ai demandé à l’équipe de ne plus introduire de bug dans le code et de rapidement corriger ceux qui venaient d’arriver !...

- Et comment ton équipe a réagit ?

- Au début, elle a dit qu’elle allait rapidement traiter les premiers bugs, et c’est ce qui s’est passé, avant d’en voir beaucoup d’autres arriver. Je crois que nous commençons à avoir de sérieux problèmes de qualité …

- Intéressant … Comment font tes développeurs quand ils ont de sérieux problèmes de qualité ?

- Et bien au début, l’équipe écrivait des tests unitaires sur le code et effectuait des revues de code pour améliorer la qualité, mais dès l’arrivée des bugs, un état d’urgence s’est installé. Aujourd’hui il n’y a plus qu’un développeur qui écrit des tests et les revues de code n’ont quasiment plus lieu ...

- Et qu’est-ce que t’as recommandé ton consultant ?

- Il me suggère de soigner ma communication ! Je me demande pour qui il se prend, ça fait déjà cinq itérations que je leur fais un feedback comme quoi ça fait trop longtemps qu’on se les traine les bugs !

- Ah Ah ! Si le feedback ne fait pas changer le système, alors ce n’est pas un feedback. Vois-tu le rapport avec les feedbacks que l’on utilise pour piloter un projet agile ?…

- Et bien, cela voudrait dire que les feedbacks que je prends à chaque itération, me donne de l’information sur le système que forme mon équipe …

- Qu’est-ce que tu aimerais voir arriver ?

- Le nombre de bugs se réduit, les développeurs sont fiers de leur travail et le développement du produit avance …

- Super ! Et du coup qu’est-ce que tu observes réellement ?

- L’équipe semble se démotiver progressivement et les bugs s’accumulent …

- Est-ce que ce que tu observes est visible et explicite ?

- Non, mais ça me donne une idée !

- Peux-tu me présenter cette idée ?

- Je pourrais demander à chacun d’indiquer chaque jour anonymement sur un poster quel est leur niveau de motivation sur une échelle de 1 à 5.

- Intéressant. Développons. Quel est ton plan d’action ?

- Outre la mesure de la motivation, je vais proposer aux développeurs de compter le nombre de bugs et de leur demander combien ils pensent pouvoir corriger par itération et leur demander combien de temps il leur faut pour remonter le niveau de qualité. Et j’adapte mon plan d’action à chaque itération.

- Bien, en tant que manager tu vas pouvoir ainsi donner à l’équipe le cadre dans lequel ces nouveaux feedbacks fonctionneront bien.  Bon ! Je descends dans deux arrêts, peux-tu me dire ce que nos échanges t’ont apporté sur la situation de ton projet ?

- Plutôt que de réagir dans l’urgence et mettre la pression sur mon équipe de développeur, je vais planifier mon plan ...

- Il faut que je descende là …

- Donc, si je me rappelle bien de notre échange, je vais planifier mon plan d’action en me posant les questions suivantes : qu’est-ce que je veux voir arriver ? Comment est-ce que je peux l’obtenir ? Puis observer ce qui se passe réellement. Est-ce que ce que j’observe est stable ? Visible ? Explicite ? Et enfin comparer ce que j’ai observé avec ce qui était planifié et adapter mon plan d’action. Ca me semble mieux pour gérer mes feedbacks.

- Super ! Essaie ça, nous en reparlerons une prochaine fois dans la ligne 9. Ok ?

- Ok !

Signal sonore. La porte se referme.