Billet #2 : La rétrospective est la clé de voûte

Comment initier le dialogue sur des bases saines ? Quels sont les actions à mettre en place pour assurer une démarche d’amélioration continue ? Dans ce deuxième billet je vous propose de revenir sur le déroulement de notre première rétrospective qui a été la clé de voûte dans la transformation de l’équipe.

Rappel : Ce billet s’inscrit dans une série de billets formant un retour d’expérience sur la transformation agile d’une équipe.

• Billet #1 : La frustration est de l’or
• Billet #2 : La rétrospective est la clé de voûte
• Billet #3 : Installer collectivement une culture
• Billet #4 : Petites boucles de rétroaction
• Billet #5 : Grandes boucles de rétro action
• Billet #6 : L’effet papillon

Poser le cadre

J’ai commencé par lire d’une manière solennelle la phrase suivante, dans le but de poser des bases saines au dialogue :

“Indépendamment de ce que nous allons découvrir aujourd’hui, nous comprenons et nous croyons vraiment que chacun a fait de son mieux, en fonction de ses connaissances, de ses compétences et de ses capacités, des ressources disponibles et de la situation courante.” (La rétrospective de sprint de Claude Aubry)

J’ai par la suite cassé le coté solennel en invitant l’équipe à échanger autour de cette phrase. Cette approche a initié le dialogue sur un sujet neutre qui n’impliquait personne en particulier, pour poser le bases d’une communication constructive.

Récolter les informations

Par la suite, j’ai proposé aux membres de soumettre les sujets qu’ils souhaitaient aborder sur des post-it, sans limitation aucune. Un grand nombre de sujets on été soumis mais tous ne pouvaient évidemment pas être abordés. Cependant, je tenais à ce que tous les sujets soient entendus au moins une fois. J’ai donc lu à voix haute tous les sujets un à un. Nous avons ensuite regroupé et classé les sujets par thèmes.

Les thèmes suivants ont émergé :

1. Réflexion et communication
2. Scrum (Itérations)
3. Recette croisée
4. Spécifications fonctionnelles

Générer les idées et définir un plan d’action

Thème #1 : Réflexion et communication

Il s’agit du thème le plus important comptabilisant le plus grand nombre de sujets soumis. Cependant l’équipe a eu beaucoup de mal à initier le dialogue. On sentait bien qu’il y avait des sujets tabous. Au bout de quelques phrases échangées sur le sujet, l’équipe a décidé de clore la conversation en concluant que ce thème était transverse et que les solutions émergeront plus facilement à travers de sujets plus concrets. Ne sachant pas comment alimenter le débat, j’ai donc respecté la décision de l’équipe.

Nous avons donc convenu de se demander comment on pouvait améliorer la réflexion et la communication dans le cadre des thèmes qui ont suivi. Cela a permis de mettre en place quelques pratiques décisives pour initier une démarche de changement saine, en accordant à l’équipe du temps pour réfléchir et communiquer.

Thème #2 : Scrum (Itérations)

Pour introduire ce thème, j’ai pris le temps de rappeler les valeurs agiles avant d’introduire les principes, les rôles, les pratiques et les artefacts Scrum pour que tout le monde ait le minimum pour aborder le débat autour de la méthodologie.

L’équipe avait besoin de gagner en visibilité en se dirigeant vers du Scrum mais la méthodologie leur semblait trop rigide. L’équipe souhaitait amorcer une démarche de changement plus douce et adaptée à leur contexte. Nous avons donc convenu dans un premier temps de partager les valeurs Agile et les principes Scrum.

Notre plan d’action pour y parvenir a été de mettre en place une réunion hebdomadaire d’une heure, animée par une personne de l’équipe pour faire le point sur l’avancement du projet.

Thème #3 : Recette croisée

Contrairement à des organisations classiques, nous ne disposons pas d’équipe dédiée à la recette. Nous avions donc intégré une phase de recette à notre cycle de développement, en reprenant le principe de revue de code et en y intégrant la recette fonctionnelle.

L’équipe trouvait cette pratique très enrichissante et souhaitait la garder telle quelle. Cependant certains développements sensibles méritaient plus de réflexion en amont afin d’éviter de tout défaire au moment de la recette croisée.

Pour éviter ce type de situation, nous avons décidé d’identifier collectivement lors de la réunion hebdomadaire les développements sensibles. L’équipe décide collectivement de soumettre ces développements, soit à une programmation en binôme, soit de précéder le développement par une phase d’analyse permettant à l’équipe de choisir la meilleure solution à mettre en place.

Thème #4 : Spécification Fonctionnelle

L’équipe a souligné le manque d’implication des parties prenantes au niveau métier, qui générait des difficultés au niveau de la compréhension du besoin utilisateur.

L’équipe avait besoin qu’un effort plus important soit mis en amont au niveau de l’étude du besoin utilisateur afin de combler le manque de disponibilité du métier.

Nous avons donc identifié au sein de l’équipe deux personnes possédant la connaissance fonctionnelle requise pour jouer le rôle de Product Owner. Leur but est de valider la cohérence et la pertinence des besoins exprimés par le métier ainsi que de formaliser, d’une manière minimale, les exigences fonctionnelles attendues.

L’apport de la première rétrospective

La réunion a duré quatre heures. Tous les sujets n’ont pas pu être traités : l’automatisation des tests et le refactoring de code (qui semblaient au premier abord être le frein principal à l’épanouissement de l’équipe) n’ont pas été abordés.

Cette réunion a permis à chacun de sortir de ses propres préoccupations en s’intéressant à celles de l’équipe.

Dans mon prochain billet nous découvrirons comment cultiver collectivement une culture agile avec une réunion hebdomadaire.

A suivre…

Retrouvez l’ensemble du Retour d’expérience avec le hashtag #AgileFromScratch