La rétrospective de sprint, diversifier pour gagner en qualité - Partie 1

Introduction

Si l’on considère l’ensemble des cérémonies préconisées par le framework SCRUM, la rétrospective de sprint est certainement celle qui peut être le principal vecteur d’amélioration continue. Pour rappel, il s’agit d’une cérémonie qui s’effectue avec l’ensemble de l’équipe de développement une fois le sprint terminé, et ne doit pas durer plus d’1h.

Négliger une cérémonie, c’est négliger une équipe

En effet, la base même de l’agilité repose sur l’échange entre individus, le développement de l’intelligence collective et la montée en compétences et en autonomie de l’équipe.

Comme il existe autant de points de vue et de ressentis que de personnes, cette cérémonie SCRUM se positionne alors comme le moment d’échanges privilégié pour les membres d’une équipe afin de :

  • gagner en bien-être et en motivation,
  • améliorer les connaissances et les relations entre individus,
  • gagner en qualité produit,
  • et enfin, gagner en productivité.

J’ai volontairement placé le bien-être et la motivation en premier dans cette liste, car ce sont pour moi ceux qui justifient à eux-seuls cet article : répéter indéfiniment le même format de cérémonie ou brûler les étapes aura des conséquences sur la qualité du produit final. Ainsi avec le temps, les membres de l’équipe vont se lasser, seront de moins en moins actifs et motivés et à termes finiront par délaisser la cérémonie ce qui aura pour effet d’occulter certains problèmes.

« Diversifiez et adaptez votre rétrospective de sprint, gardez-la vivante ! »

Une méthode c’est comme un T-shirt, il faut en changer de temps en temps

La base de la base

Je ne vais pas revenir sur la méthodologie SCRUM et ses fondamentaux (quand, combien de temps, qui participe…) qui sont abordés dans l’article de l’astronaute Charles-Eric « Amélioration continue : comment animer vos rétrospectives agiles ». Je tiens seulement à préciser que peu importent la « gamification » ou le support visuel/matériel utilisé pour la rétrospective, cette dernière aura quasi-essentiellement toujours ce type de structure, pour une durée n’excédant pas 1h :

  • Ouverture
  • Recueil des données
  • Génération d’idées
  • Définition d’actions à mener
  • Clôture

Pourquoi avoir mis en gras le « recueil des données » ? Eh bien tout simplement parce que les différents types de rétrospectives abordés ensuite vont essentiellement se concentrer sur cette section. Libre à vous ensuite de vous approprier les autres étapes et d’innover. J’ai par exemple déjà vu quelqu’un mettre la BO de Skyrim en introduction de cérémonie, et de narrer l’ensemble un peu à la manière d’un MJ (entendez ici : maître du jeu, comme dans un « donjon et dragons » ou autre jeu de société).

Pourquoi changer alors ?

Effectivement, pourquoi vouloir changer quelque chose qui fonctionne si vous avez déjà votre type de rétrospective favori ? Nous avons déjà eu quelques éléments de réponses plus haut : l’équipe va se lasser et on peut passer à moyen et long terme à côté de problématiques qui n’émergeront pas… Mais cela peut aussi être tout autre, par exemple une équipe peu mature sur l’Agile aura parfois du mal à s’approprier le type de rétrospective « imposée », des personnes timides pourraient aussi ne pas réussir à s’exprimer pleinement avec tel ou tel type de rétro…

Vous l’aurez compris : plus on creuse, plus on trouve des aspects négatifs à réitérer indéfiniment le ou les mêmes types de rétrospectives. On pourrait alors tout à fait imaginer qu’outre la perte de motivation et d’engouement pour cette cérémonie, l’équipe pourrait aussi passer à côté d’un problème de bien-être global (ou quelque chose d’extérieur) car les rétrospectives proposées ne se concentrent que sur les aspects négatifs ou sur des problèmes de « surface ». Bien entendu, comme expliqué dans un autre article, vous pourriez aussi commencer la cérémonie avec un mood board ou un safety check afin de vous en donner un aperçu et ensuite orienter vers tel ou tel type de rétrospective

Enfin, de manière beaucoup plus situationnelle, on pourrait aussi imaginer que vous n’avez pas une multitude de choses à aborder et qu’un système type START, STOP, CONTINUE va sembler un peu vide et ressemblant au dernier, alors que l’équipe cherche un moyen intelligent d’aborder un énorme problème. Il existe justement un type de rétrospective adapté à ce cas de figure.

Munissez-vous de nouvelles armes, la suite de l’article vous donnera un petit tour d’horizon pour changer de type de rétrospective !

La liste d’ingrédients pour changer de recette, partie I

Avoir envie de changer est une chose, changer efficacement en est une autre. Pour cet article, on ne s’attardera que sur quelques suggestions qu’on regroupe donc en 3 catégories, ayant chacune un avantage ou une spécificité propre. Bien entendu, il ne s’agit là que d’un découpage purement personnel, je suis ouvert aux commentaires. Je profiterai d’un second article pour aborder les 2 catégories suivantes, nous ne nous concentrerons dans un premier temps que sur les formats classiques.

N’oubliez pas de time boxer les différentes étapes, et d’essayer de ne pas dépasser 1h au total.

Les formats classiques

Il existe des formats « de base », incontournables, et dont l’efficacité est très largement prouvée, vous les connaissez déjà sûrement. Ce sont souvent de bon points d’entrées pour des équipes qui débutent en SCRUM, ou pour des équipes plus matures sur les premiers sprints par exemple.

Stat, stop, continue

start_stop_continue_sprint_review Préparation

  • Des posts-it de 3 couleurs
  • Un stylo par personne
  • Un tableau blanc, un mur ou un paper-board

Déroulement de Start, Stop, Continue #Etape 1 : Le Scrum master va expliquer les 3 colonnes et demander aux différents participants d’écrire ce qu’ils pensent dans chacune des colonnes (une idée par post-it)

  • « Start », ce que le membre de l’équipe pense qui devrait être ajouté au processus. Par exemple montrer plus rapidement le produit au client pour avoir des feedbacks, éviter les retards aux réunions, faire plus d’inspections de code, mieux découper les users-stories.

  • « Stop », ce que le membre d’équipe pense qui est fait actuellement et qui est une perte de temps ou est inefficace. Pour l’exemple, on pourrait avoir des choses sur la trop longue durée des réunions, effectuer trop de backlog refinement, ou encore effectuer des revues de code avant que ce dernier n’ait passé tous les tests.

  • « Continue », ce que le membre d’équipe pense qui doit être amélioré ou qui est une bonne chose, mais pas encore une véritable habitude. #Etape 2 : Le Scrum master demandera ensuite aux participants d’aller coller sur le tableau les différents post-it et réorganiser ces derniers si des thématiques sont identiques. Si certains ne sont pas très compréhensibles ils peuvent être réécrits.

#Etape 3 : Le Scrum master va maintenant demander à chacun d’expliquer les tickets au tableau. Pour cette partie le Scrum master peut choisir de discuter des post-it dans l’ordre, ou de faire l’emphase sur certains uniquement.

#Etape 4 : Le Scrum master va maintenant demander aux membres de l’équipe de prendre quelques minutes pour noter sur des post-it des axes d’améliorations, avec toujours une idée par post-it.

#Etape 5 : On terminera par un dot voting afin de voter pour les 3 axes d’améliorations les plus importants et qui devront être mis en action pour le prochain sprint. On donnera donc à chacun des membres 5 points qu’ils devront répartir sur les tickets. Une fois les 3 axes sélectionnés, on définira des responsables pour chacun des axes, afin de s’assurer qu’ils seront implémentés au cours du prochain sprint.

Mon Avis Dans cette méthode on se focalise essentiellement sur le produit. Elle est certe facile à mettre en place et est très efficace, mais sur le long terme il faudrait pouvoir donner la possibilité à l’équipe d’exprimer son ressenti sur le projet et ses émotions.

KALM

KALM_sprint_review Préparation

  • Des posts-it (une seule couleur)
  • Un stylo par personne
  • Un tableau blanc, ou un paper-board
  • Un feutre pour tableau blanc (si tableau blanc)

Déroulement de KALM #Etape 1 : Le Scrum master va expliquer les 4 espaces du tableau et demander aux différents participants d’écrire ce qu’ils pensent dans chacun (une idée par post-it). On prendra à chaque fois 5 à 10 minutes par case avant de passer à l’écriture de la suivante. On collera les éléments après chaque fin de cycle sur le tableau qui aura au préalable été découpé en 3 blocs (keep, less, more) et une rubrique « add » qui vient « oxygéner l’ensemble ».

  • « Keep », ce que l’équipe fait et qui apporte de la valeur, reconnue par tous.

  • « Less », ce qui est trop fait actuellement et qui pourrait être moins fait, sans impact majeur sur le projet.

  • « More », ce qui est déjà fait actuellement mais qui, si plus fait, apporterait encore plus de valeur.

  • « Add », ce sont les nouvelles idées, par exemple des choses qui ont pu être vues ailleurs et qui pourraient fonctionner ici.

#Etape 2 : Le Scrum master va maintenant réorganiser les post-its (si certains sont identiques) et demander à chacun d’expliquer les tickets au tableau. Pour cette partie il est préférable de discuter des post-its dans l’ordre.

#Etape 3 : Le Scrum master va maintenant demander aux membres de l’équipe si elle souhaite rajouter des « actions d’améliorations » ou si on considère que les post-it de improve sont les actions à mettre en place.

#Etape 4 : Le Scrum master va maintenant demander aux membres de l’équipe de prendre quelques minutes pour noter sur des post-its des axes d’améliorations, avec toujours une idée par post-it.

#Etape 5 : On terminera par un dot voting afin de voter pour les 3 axes d’améliorations (post-it « add ») les plus importants et qui devront être mis en action pour le prochain sprint. On donnera donc à chacun des membres 5 points qu’ils devront répartir sur les tickets. Une fois les 3 axes sélectionnés, on définira des responsables pour chacun des axes, afin de s’assurer qu’ils seront implémentés au cours du prochain sprint.

Mon avis À la différence des deux précédents, on fait l’emphase sur la génération de valeur ressentie par l’équipe. C’est donc une variante très intéressante et facile à mettre en place très rapidement sur des sprints. Elle conviendra aussi bien aux novices (tant qu’elle est bien expliquée) qu’aux confirmés.

CONCLUSION

J’espère que cet article vous aura fait comprendre l’intérêt de diversifier les formats de vos rétrospectives et vous en aura fait découvrir de nouveaux (au au moins revoir vos bases).

La répétition inlassable des cérémonies Scrum est son propre ennemi, il est vite facile de s’en désintéresser et d’abaisser le niveau global de retours sur le processus et le projet… mais il est tout aussi facile d’en diversifier les formats. Nous n’avons abordé ici que les formats classiques, je profiterai d’une suite à cet article pour aborder 2 autres catégories qui vous permettront de pousser la réflexion un peu plus loins, et surtout de gamifier un peu cette cérémonie.

Essayez-vous déjà à ces différents formats et venez partager en commentaire vos REX et suggestions de type de rétrospectives !

RÉFÉRENCES