Billet #4 : Petites boucles de rétroaction

Comment orchestrer le sprint ? Peut-on autoriser le changement de scope ? Comment garantir la qualité sans une équipe de recette ? Comment gérer les livraisons ? Ce quatrième billet exposera notre façon de travailler ainsi que les indicateurs que nous avons mis en place pour nous aider dans notre démarche d’amélioration continue.

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

Réunion hebdomadaire

Préparation

La personne en charge de l’animation est aussi responsable du report du temps passé hors « tâche spécifique » pour l’ensemble de l’équipe. Elle collecte et reporte dans Jira les temps prévus pour les réunions et les absences.

Ce temps est réparti dans l’outil en quatre, à savoir :

• le temps prévu découpé en deux catégories pour les réunions et les absences
• le temps imprévu découpé aussi en deux catégories pour les absences et autres (réunion commerciale, problème matériel, etc..)

Cette pratique nous permet de ne pas perdre du temps pendant la réunion pour calculer la capacité de l’équipe. Si ces informations sont détaillées en plusieurs « activités », c’est parce qu’on les utilise à une autre fin dont je vous parlerai plus tard.

Déroulement

Rétrospective

L’équipe passe en revue les graphiques Scrum classiques en prenant en compte les éventuels changements de périmètre du Sprint. Au changement de périmètre près, c’est du classique Scrum.

Nous allons plutôt nous intéresser à une pratique moins classique. L’équipe a mis en place un « dashboard » sous JIRA qui permet d’avoir une vision sur l’avancement des différentes tâches. Il expose la liste des tâches du Sprint avec les indicateurs suivants : le ratio temps passé par rapport au temps estimé et la cause éventuelle de dépassement.

L’équipe revoie donc toutes les tâches du Sprint et discute autour de ces indicateurs afin de comparer ce que nous avions prévu par rapport aux résultats obtenus et adapte donc sa conduite en fonction. Par exemple : le « refactoring » de certaines parties du codes qui ont causé des dépassements.

Lancement du Sprint

Après avoir fait le bilan, l’équipe planifie le Sprint suivant et la date éventuelle de livraison en fonction de l’avancement des tâches.

De leur coté, les proxy POs présentent les différentes tâches à inclure dans le prochain Sprint. De son côté, l’équipe pose des questions et chiffre les tâches en jour-homme idéal.

Pour encourager l’implication de l’ensemble de l’équipe, les tâches ne sont pas attribuées lors de la planification. Comme en kanban, l’équipe doit traiter les tâches par ordre de priorité et donc n’importe qui peut être amené à développer n’importe quelle tâche.

Petite itération

Déroulement

L’équipe travaille sur des sprints d’une semaine. La durée du sprint est courte afin de pouvoir intégrer rapidement les changements de priorité.

Durant le sprint, comme en kanban, on applique aussi une limitation sur le travail en cours : chaque personne travaille sur une tâche à la fois.

Le processus de validation des demandes est intégré dans le sprint. Le but de l’équipe est de fluidifier le cycle de vie des demandes et éviter ainsi les goulots d’étranglements qui pourraient être dus à la recette.

Au cours d’un sprint, l’équipe peut être amenée à travailler sur plusieurs versions du produit :

• Une version majeure en cours de développement
• Une ou plusieurs versions mineures contenant des correctifs et des évolutions mineures

Nous travaillons ainsi car la livraison d’une version majeure implique une phase de recette générale de l’application, alors qu’une version mineure peut être livrée plus facilement car elle contient des développements non impactants.

Les fréquences de livraisons sont variables en fonction de l’avancement des tâches et de l’urgence du besoin.

Les grandes boucles de rétroaction

Le fonctionnement en petites itérations est parfait pour l’équipe afin d’avancer tout en faisant des points régulièrement, tout en mettant en place des actions en fonction de ce qu’elle a appris durant la semaine.

Cependant, certains sujets méritent une période d’expérimentation plus longue. Je vous propose de traiter ce sujet dans mon prochain billet afin de vous expliquer dans les détails le fonctionnement de nos grandes boucles.

A suivre…