Effectuer régulièrement des rétrospectives agiles aide les équipes à apprendre et à s'améliorer. Vous pouvez rendre les rétrospectives plus efficaces en y ajoutant des objectifs et en validant si les actions des rétrospectives mènent au progrès, grâce à des hypothèses.
Le manque de suivi est une des raisons principales pour lesquelles les rétrospectives échouent parfois à apporter des progrès, comme Thomas Cagley le décrit dans Les obstacles de la rétrospective :
La pire erreur qu'une équipe puisse commettre est d'effectuer une rétrospective et de ne rien faire avec les résultats. Même si la discussion peut elle-même avoir été revigorante ou cathartique, à la fin, l'équipe a gaspillé son temps.
Pour s'assurer que les actions soient entreprises, Thomas suggère de rendre le progrès nécessaire explicite et visible :
Chaque rétrospective devrait identifier au moins un objectif ou une idée d'amélioration. Cet objectif devra être ajouté au sprint backlog et être traité comme n'importe quel autre élément que l'équipe s'est engagée à délivrer.
Dans l'article Rétrospectives excellentes, Dave Sharrock explique comment rendre les rétrospectives efficaces en donnant un objectif à la réunion :
(...) la manière la plus simple d'injecter un autre niveau d'énergie dans la rétrospective est simplément de fournir un but, en définissant une question claire au début, autour de laquelle réfléchir.
Pour être rentable, le but doit être clair pour tous, pertinent et surtout pas égoïste. Cela peut être focalisé sur la découverte de problèmes spécifiques tangeants au succès du sprint lui-même (e.g. qu'est-ce qui doit changer pour que l'équipe puisse délivrer deux fois plus de stories sur la même période de temps ?) ou ciblé sur les problèmes organisationnels ignorés par l'équipe (e.g. comment réduire ou éliminer l'attente d'approbation réglementaire de conformité pour les nouvelles fonctionnalités ?).
Bob Marshall explique, dans Rétrospectives - Plus faux et plus vrai, pourquoi il considère le cycle PDCA, qui démarre avec une hypothèse, comme l'une des racines des rétrospectives :
Comment rendre les rétrospectives ordinaires extraordinaires ? Retourner à ses sources ; plus précisément, au PDCA (le Cycle Shewhart). Beaucoup de monde voit le mot "Plan" dans le simple contexte, par exemple, de Sprint Planning et Release Planning (Scrum). Mais dans un PDCA approprié, comme décrit dans la "Méthode Scientifique" originale de Francis Bacon, "Plan" signifie hypothèse :
- "hypothèse" - plan
- "expérimentation" - do
- "évaluation" - check
- "contrôle" (une addition tardive) - act
Dans ce schéma, toute rétrospective est inutile sauf si elle répond à la question "est-ce que ce que nous espérions - notre hypothèse - s'est réalisé"? Si oui, pour quelle raison ? Si non, pourquoi pas ? Sans cette hypothèse initiale, nous ne pouvons jamais nous poser cette question.
Marc Löffler a écrit l'article Injecter un objectif aux rétrospectives, dans lequel il explique que le manque d'objectif est la cause principale à traiter pour faire de meilleures rétrospectives :
Toute rétrospective sans objectif est une perte de temps (et cela vaut pour toute autre réunion). Ca n'a aucun sens de changer régulièrement votre rétrospective et d'y introduire de nouvelles idées, s'il n'y a pas d'objectif derrière.
Il a adapté le processus de rétrospective du livre de Diana Larsen et de Esther Derby : Agile Retrospectives, en utilisant les hypothèses de la même façon qu'elles sont utilisées dans le Lean Startup. Marc a étendu l'étape "décidez de ce que vous faites" avec une étape "ajoutez des hypothèses", et a introduit une étape "vérifiez les hypothèses" après avoir récupéré les informations :
(...) au lieu de générer un aperçu, vous vérifiez les hypothèses de la rétrospective précédente. C'est très puissant, car cela offre la possibilité de vérifier si les tâches des dernières rétrospectives ont eu l'effet escompté (vos hypothèses). Dans la plupart des cas, vous réaliserez que vos hypothèses étaient fausses. En plus de simplement vérifier si vous avez travaillé sur toutes les tâches identifiées la fois précédente, vous vérifiez aussi si elles ont été utiles et ont eu un effet positif. Si vos hypothèses étaient fausses, cela vous donne l'opportunité de vérifier la raison pour laquelle elles n'ont pas eu l'effet espéré.
Ajouter des hypothèses et les vérifier à la rétrospective suivante donne, d'après Marc, un objectif aux rétrospectives. Et cela aide à vérifier si les actions de la rétrospective sont rentables :
Vous devez ajouter une hypothèse à toutes les tâches identifiées, ou vous ne serez pas en mesure de vérifier si elles ont été utiles. Soyez sûrs que vos hypothèses sont testables comme décrit dans la méthode scientifique. Si votre hypothèse n'est pas testable, elle n'a aucun sens.
Bob Boyd fournit un processus en 8 étapes pour faire des rétrospectives avec validation scientifique. Suivant les concepts du lean startup, ces étapes vous aident à valider si les actions de vos rétrospectives ont eu l'amélioration espérée:
- Définissez clairement le problème que l'amélioration doit résoudre
- Définissez clairement ce que doivent être les résultats avec la mise en place de l'amélioration
- Développez l'hypothèse falsifiable de l'amélioration (c'est le résumé de l'expérimentation)
- Identifiez les métriques et les mesures à récupérer
- Identifiez la manière dont les métriques sont collectées
- Identifiez la manière dont les informations collectées sont présentées
- Identifiez la manière dont l'équipe saura que l'hypothèse a été démontrée au-delà de tout doute raisonnable
- Identifiez la manière dont l'équipe saura que l'hypothèse a été réfutée au-delà de tout doute raisonnable