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.
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 :
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"
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 :
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é).
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 !
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.
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.
Préparation
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.
Préparation
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.
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 !
Auteur(s)
Pierre Brenot
Product Manager / Product Owner aka dealer de cadre et de solutions pour projets digitaux
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
Suivant le cycle de vie du produit et de l'ambition de l'entreprise, il est courant de faire appel à une équipe de développement externe pour réaliser tout ou partie de la prochaine version du produit. La préparation de l'arrivée de la nouvelle équipe est souvent négligée mais pourtant cruciale. Cet article a pour objectif de tracer les grandes lignes de cette préparation en amont.
On parle tout le temps de Product Managers "apporteurs de solutions" (ou "problem solvers" en anglais) qui sont là avant tout pour résoudre des problèmes et faire avancer les choses. Le souci c'est qu'on a beaucoup trop tendance, à assimiler ce trait à la capacité de la personne à dire oui plutôt que NON. Un bon Product Manager doit savoir dire NON quand il le faut, et de la bonne manière.
Écrire une User Story efficace n'est pas un exercice simple et cela nécessite de l'entraînement, même si à première vue "il ne s'agit que d'une petite phrase courte". Comme en développement, il ne s'agit jamais "que" de cela. Dans le cadre d'un projet AGILE vos Users Stories sont la transcription du besoin des différentes parties prenantes, découpées en incréments fonctionnels.