Les rétrospectives dans l’équipe dans laquelle je travaille laissent beaucoup de place à l’amélioration : En fin de sprint de deux semaines on fait un tour de table pour avancer les points positifs et les points d’amélioration. Point.
On était deux dans l’équipe à souhaiter quelque chose de plus ambitieux. Alors on s’était renseigné pour avoir une personne extérieure à l’équipe, voire un coach. Pour divers raisons rien s'était passé en six semaines, alors on a décidé d’améliorer ce que nous avions déjà avec les moyens du bord. Le déclencheur a sans doute été notre présence à XP Days Suisse où nous avons assisté à une session sur les rétrospectives (compte rendu de Bruno Orsier, Luc Jeanniard)
Nous avons commencé par revoir la dernière rétrospective pour savoir s’il y avait des points importants qui n’avaient pas été adressés. Ensuite nous avons conduit la rétrospective comme avant.
Au lieu de laisser les points d’amélioration cachés dans une page au fond d’une application quelque part, nous avons priorisé les points. Chacun pouvait voter pour les deux points qu’il trouvait les plus important. L’engagement était de faire quelque chose pour les 2-3 points les plus importants dans le sprint suivant. Voici nos points :
- Améliorer la qualité des scénarios de BDD (Behavior driven development)
- Diminuer le délai entre le début d’une livraison et la mise en production (le problème étant surtout un problème de délai et non de charge de travail)
- Faciliter le ramp-up de deux collaborateurs arrivés récemment en imprimant un schema de la base de données.
Le point 3 étant très simple nous l’avons simplement fait le lendemain.
Pour améliorer la phase de déploiement nous avons décidé d’actions concrètes :
- Evaluer en détail la faisabilité de plusieurs pistes connus pour simplifier la procédure de déploiement, notamment en éliminant les tâches manuelles.
- Décrire au moins deux options d’architecture pour permettre un blue-green deployment.
Ces deux actions ont été planifiées dans le sprint AVEC une priorité importante – afin d’être sûr qu’elles seront adressées.
Finalement pour adresser le premier point nous avons discuté avec tous les acteurs concernés afin d’établir un plan d’action. Le voici :
- Product Owner : exprime ses idées à travers un scenario
- afin de venir avec des propositions plus réfléchies
- Product Owner + Scrum Master + Dev Lead : font des backlog reviews systématiques avant le sprint planning. Cette réunion donne lieu à deux livrables
- DraftScenarios (Des scenarios suffisamment précis pour une estimation en poker planning)
- Une priorisation du product backlog
- Product Owner + dévelopeur(s) : écrivent ensemble les GoScenarios ( ce qui signifie des scenarios prêts pour être développés).
Conclusion
Avec des améliorations ultra simples nous allons, je pense, tirer beaucoup plus des rétrospectives qu’auparavant. C’est tellement simple que j’avais l’impression que c’était bête d’en blogger, mais à mon avis cette équipe n’est pas la seule à faire des rétrospectives bâclées. Et cette expérience montre que même avec peu de moyens en temps et en connaissance on peut faire des améliorations importantes.
Prochaines étapes :
- Lire ce livre
- Faire une rétro un peu plus longue en jouant toutes les phases d'une rétro avec root cause analysis
- Afin d'avoir des animateurs qui ne font pas parti de l'équipe (c'est plus facile d'animer une retro si on est partie prenante!) on a eu l'idée qu'un de nous fasse la rétro d'une autre équipe et que cette autre équipe nous rende le service.
