Ayant travaillé au sein d’équipes utilisant des méthodologies agiles depuis plusieurs années, les rétrospectives sont une partie importante de ma vie en tant que chef de produit. Des rétrospectives (rétros) ont lieu à la fin de chaque cycle de sprint, à la fin de la version globale et parfois pour passer en revue d’autres réunions ou processus. Retros est destiné à évaluer les succès et les échecs de votre équipe, dans le but d’une amélioration continue.
Les Retros sont un excellent moyen d’améliorer la communication et de favoriser le travail d’équipe. Une équipe ouverte et respectueuse de ses collègues aura beaucoup plus de succès qu’une équipe qui bavarde sur la fontaine à eau car Johnny n’a pas écrit de cas de test. Une rétrospective exécutée avec succès aurait mis en évidence le fait que les cas de test sont extrêmement importants et ne doivent pas être négligés, une conversation suivie d’une action livrable pour aller de l’avant.
D’après mon expérience, cependant, le plus souvent, les réunions rétrospectives deviennent juste une autre cérémonie agile.
Pourquoi les rétrospectives pue
À la fin de chaque sprint, les équipes de développement du monde entier se rassemblent dans une salle ou se connectent aux lignes de conférence pour revoir le travail accompli lors du sprint ou de la version précédente. Ces réunions peuvent aller dans plusieurs directions différentes.
Si votre équipe a réussi au cours du dernier sprint, les rétrospectives ne sont pas productives – une réunion qui aurait pu être évitée et à la place commémorée avec un grand giphy «pouce en l’air» à Slack. Au lieu de cela, vous passez une heure à fendre les cheveux afin de trouver quelque chose regarder en arrière.
À l’inverse, si votre équipe n’a pas réussi un sprint, vous vous retrouverez avec une liste longue d’un kilomètre d’actions. Une liste d’actions qui ne sont généralement pas exécutées ou suivies. Ces listes sont documentées dans une page ou une note de Box perdue depuis longtemps. Si votre équipe est vraiment sur leur jeu, ces éléments d’action sont examinés lors du prochain rétro.
Comment les réparer
N’ayez pas peur de sauter
Chez Ncino, nous avons constaté que les rétrospectives ne sont qu’une autre étape de notre cycle de développement. À la fin de chaque sprint, bon ou mauvais, nous nous réunissons pour discuter de la façon dont cela s’est passé. Nous avons constaté que si l’équipe estimait à l’unanimité que le sprint était réussi, sauter cette rétrospective particulière s’avérait plus utile que de l’avoir.
Si vous n’avez rien de majeur à discuter, n’ayez pas peur de sauter, ou du moins de raccourcir, votre rétrospective.
Célébrez que votre équipe l’écrase, travaille ensemble efficacement et respecte les engagements de sprint.
Au lieu d’utiliser une heure pour parler de votre talent, rendez cette heure à votre équipe de développement pour continuer à l’écraser!
Time-box et respectez-le
Fixez vos rétrospectives à moins d’une heure. Après une heure à tourner autour des succès ou des échecs d’un sprint précédent, vous avez probablement couvert les principaux problèmes (et probablement dans toutes les colonnes; Démarrer, Arrêter et Continuer), ou vous avez contrarié Dave, votre développeur principal, qui prend les choses trop personnellement. Avec 10 minutes restantes dans votre rétrospective encadrée, commencez à commémorer vos éléments d’action.
Si vous constatez que vous n’avez pas besoin de toute l’heure, notez vos actions, donnez-en quelques-uns, et terminez tôt.
Une façon dont mon équipe a résolu le problème des délais est de s’assurer que nous nous préparons. Nous utilisons Ideaboardz.com comme un simple outil de collaboration pour poser nos sujets rétro. Nous l’envoyons quelques jours avant la prochaine rétrospective, donnant à chacun suffisamment de temps pour prendre note de la façon dont le sprint s’est déroulé. De cette façon, nous savons exactement ce que nous devons couvrir. Être préparé nous a permis de nous en tenir à l’horaire et, la plupart du temps, de terminer tôt.
Essayez-le et voyez comment cela fonctionne avec votre équipe.
Agissez sur vos actions
Écrivez-les. Imprimez-les et postez-les dans la zone de l’équipe de mêlée. Partagez les éléments d’action avec un public plus large ou entre différents services. Collez une note autocollante sur votre moniteur. Faites quelque chose pour suivre vos actions.
Sans suivre et mesurer vos résultats, je vous promets qu’ils seront oubliés, brossés sous le tapis; quand ils sont inévitablement redécouverts lors d’un autre rétro comme un problème continu, vous vous retrouvez à dire “C’était une bonne idée … pourquoi n’avons-nous pas fait cela?”.
Après avoir échoué plusieurs fois avec le suivi des éléments d’action, nous avons commencé à les écrire sur un tableau blanc de la zone commune. Cette action simple nous aide à garder les sujets à l’esprit et garantit que nous ne les négligeons pas.
Conclusion
Pour être clair, je ne préconise pas de sauter les rétrospectives. Ces sessions peuvent être très productives et ajouter une tonne de valeur si elles sont exécutées correctement. L’amélioration continue est essentielle pour les magasins agiles et les rétros offrent la possibilité de faire une pause, de regarder en arrière et d’évaluer afin d’améliorer la progression. Cependant, si elles ne sont pas exécutées correctement, les rétrospectives peuvent entraîner une perte de temps improductive qui n’apporte pas de valeur à l’équipe. Tirez le meilleur parti de vos rétrospectives (lorsque cela est nécessaire) et assurez-vous que les actions sont réellement poursuivies, et je pense que vous trouverez vos équipes de mêlée fonctionnant comme des machines bien huilées.
