Deux membre de l'équipe de la startup TEA sont venus partager leur expérience d'amélioration continue lors d'une conférence au Mix-IT.
Au menu : demos, retrospectives, revue de code, amélioration du ROTI des réunions, outils et méthodes. ....
Commençons donc par le début qui est aussi la fin d'un sprint la coupure de sprint. Celle-ci se compose de la démonstration, la rétrospective et enfin la phase d'engagement pour le sprint suivant. Partie importante et même incontournable il est assez courant que la démonstration prenne beaucoup de temps, soit parce qu'elle se passe de façon brouillonne soit parce que les participants l'interrompent avec des questions posées à brûle-pourpoint. De fait l'équipe, confronté à ce problème de durée, en a réduit la durée (sans en diminuer le feedback) en :
- scénarisant la démonstration.
- encadrant le débat et en le time-boxant.
Les conséquences de ces modifications sont une réduction drastique, comme indiquée plus haut, de la durée de la démo (50' => 20aine de minutes), l'envie de l'équipe d'inviter des participants à la démonstration ( augmentation de la confiance et de la fierté vis à vis du code montré), et l'augmentation de l'impact de la démonstration sur les invités.
Ensuite les speakers ont abordé le sujet sensible de la rétrospective. Au départ le format de la rétrospective chez TEA consistait à un tour de table en mode Start Stop Continue. Le problème de ce format est que, si il est adapté à une petite équipe il devient vite trop lourd pour une équipe conséquente, les participants étant passés ou devant passés n'écoutant plus forcément le membre de l'équipe en cours d'expression. Pour palier à ce problème l'équipe a changé de format et ce dans le but de raccourcir la rétrospective (but que je ne trouve pas forcément louable! ). Le nouveau format se découpe en trois étapes :
- collecte des faits.
- lister ce qui a été appris au cours du sprint.
- lister les actions à essayer pour le prochain sprint en vue de s'améliorer sur les points levés en 1 et 2.
Ce format a aussi été l'occasion d'introduire pour l'étape 1 des jeux agiles basé sur l'utilisation de post-it. Après quelques essais une limitation du nombre de post-it par participant a été mise en place, cette limitation n'a pas amené de gain en terme de temps mais a par contre amélioré les débats sur le contenus des post-it. Au global la rétrospective n'a pas été réduite en durée mais le feedback et le ROTI de celle-ci ont, de l'avis de l'équipe, été grandement améliorés. Il faut toutefois veiller à ne pas créer de frustration par une trop grande limitation du nombre de post-it et ne pas hésiter à changer de format si le besoin s'en fait sentir.
Puis a été abordé la phase d'engagement, phase au cours de laquelle l'équipe découpe en tâches le scope fonctionnel du prochain sprint et le chiffre. Cette phase est de loin la plus longue de la coupure de sprint. Au départ l'équipe faisait en une seule phase de trois heures le découpage, le chiffrage puis l'engagement (définition du backlog de sprint). Ce format a pour défaut de générer une fatigue importante des participants et parfois on constate une baisse de motivation et donc de la qualité des chiffrages produits. Pour améliorer ce point, TEA a découpé cette dernière phase en petites réunions de découpage / chiffrage. Cette approche à permis d'obtenir un meilleur focus sur la production des réunions mais n'est pas forcément suffisante pour obtenir un résultat constant en terme de qualité. Dans le cadre d'un projet actuel avec des sprints de 4 semaines il me parait effectivement pertinent de découper la partie identifications des tâches en petites réunions et de faire une phase chiffrage / engagement à la fin. La préparation des réunions successives sur un périmètre plus restreint devant amener une amélioration qualitative du découpage qui aujourd'hui prends plus de deux heures et se fini, à mon avis, un peu à l'arrache (sans parler du chiffrage).
Ensuite les speakers on exposé les méthodes / outils utilisés chez TEA. On y apprend qu'ils sont globalement en SCRUM, mais passent parfois en mode KANBAN pour "rassurer le business". A mes yeux c'est un des points discutables de l'approche, je ne pense pas qu'un changement de méthode doive intervenir dans le seul but de rassurer, et d'apporter de la visibilité aux gens extérieurs à l'équipe. Côté pratiques de développement on retrouve :
- code review => croisement systématique en binôme : présentation de la conception puis revue de l'implémentation après réalisation.
- mise en place d'un processus de pull request systématiques
Des évolutions dans l'environnement de travail ont été testés notamment l'utilisation d'ordinateurs portables au lieux de poste de bureau, le constat tiré est que ce mode de fonctionnement a amené une meilleurs disponibilités des séniors pour accompagner les juniors (le dev sénior pouvant s'installer proche du junior tout en continuant à travailler sur ses sujets), n'a pas éliminé le pair-programming (même si il faut porter attention à ne pas laisser tomber cet outil favorable à l'amélioration de la qualité de code) tout en conservant la possibilité de travailler en solo ou en pair programming. Par contre attention à la dérive consistant à continuer à coder alors qu'on est en réunion!!! Par ailleurs une forme de gestion du recrutement originale est évoquée, en effet l'équipe essaye d'accueillir les candidats en immersion sur une demi journée, cela permet d'avoir un bon aperçu du candidat par l'équipe et vis-versa mais ne constitue pas une évaluation technique de celui-ci. Juste un moyen d'avoir un échange plus libre et informel et de tester le matching candidat / potentielle future équipe. Par contre ce mode de fonctionnement est chronophage pour l'équipe. L'intégration d'un nouveau développeur se fait via pair progamming, le nouveau n'étant pas intégré à la capacité de production (ce qui me semble une bonne approche !!! ) et, comme pour le projet ou je travaille à l'heure actuelle, la montée en compétence passe par une confrontation à la plate-forme par l'exploitation ( résolution de pb de production).
Enfin une bref évocations de choses qui n'ont pas été concluantes est fait notamment le Niko Niko (évaluation de l'humeur des membres de l'équipe), la limitation des stories en cours....
En conclusion Je retiens que pour s'améliorer dans un contexte agile, il faut régulièrement challenger ce qui est mis en place (ré-évaluation du rapport coût/intérêt) et s'autoriser à essayer de nouvelles choses. Je sors de cette conférence avec quelques pistes à explorer pour le projet dans lequel je suis impliqué et d'autres pistes de réflexions à titre personnel. Merci à Anne-Sophie Tranchet et Olivier Servieres pour ce retour d'expérience!
- Nicolas's blog
- Log in or register to post comments
Comments
Précisions
Merci beaucoup pour ce résumé et ces impressions, ça fait vraiment plaisir !
Quelques petits compléments et précisions :
- Une des mesures principales de la démo a aussi été de scinder démo et questions du public : ces dernières ne sont posées qu'à la fin et n'interrompent en aucun cas la démo.
- Concernant les rétrospectives qui commençaient à devenir indigestes : on a effectivement pensé que la solution était de les raccourcir, et comme tu le sous-entends, on s'était trompé là dessus. Et par hasard, en prenant des mesures pour tenter de la raccourcir, on est arrivé à d'autres résultats plus intéressants. Le talk étant construit comme un REX au jour le jour, je n'ai probablement pas assez insisté sur le fait qu'on avait mal identifié notre problème à la base mais qu'on ait réussi à retomber sur nos pattes ;)
- Le passage de Scrum à Kanban, ça ne m'étonne pas que ça génère des réactions, c'est un sujet sensible. Il y a effectivement une part de "on va rassurer le business" dans le fait de prendre nous même la décision de le faire avant qu'on nous l'impose. Mais en dehors de ça, dans ces rares périodes vraiment difficiles, on a un vrai problème avec le principe d'itération. Pour ma part, je suis assez partisan de baisser temporairement la durée des itérations en cas de besoin (j'ai déjà fait des itérations de moins d'une semaine, avec changement total du format de la coupure de sprint pour aller très vite). Mais c'est très fatigant, c'est chaotique les premières fois, et je n'ai pas trouvé le besoin assez fort pour soumettre l'idée chez TEA.