Le idea Rétrospective a existé presque toujours, mais pas toujours avec ce nom. Depuis que les humains existent, nous avons regardé ensemble une activité, pour essayer d’en tirer des leçons. Après une chasse, après une naissance, après un match, après une opération, and so on.
Norman Kerth a été le premier à l’appeler « Retrospective » dans le monde informatique, dans son livre : Rétrospectives de projet – un manuel pour les revues d’équipe à partir de 2001. Il a décrit une méthode formelle pour préserver les précieux enseignements tirés des succès et des échecs de chaque projet. Avec des scénarios détaillés, des illustrations imaginatives et des directions étape par étape, ce livre a commencé mon voyage en tant que facilitateur de rétrospective. J’ai adoré l’idée et j’ai commencé à la mettre en œuvre, d’abord dans ma propre équipe, puis dans d’autres équipes et plus tard, en dehors de mon organisation. Les activités « Directive principale »,
« Développer une ligne du temps », « Je suis trop occupé » et d’autres activités sont tirées de son livre.
Plus tard, Diana Larsen et Esther Derby ont écrit le livre : Rétrospectives agiles – Rendre les bonnes équipes formidables. Cela a introduit des rétrospectives plus courtes qui s’intégreraient dans des processus agiles. Cela a changé la donne pour moi. Leur livre m’a aidé à planifier des rétrospectives plus courtes et plus efficaces, mais contient également des outils pour l’animateur qui m’ont aidé dans le processus réel de planification des rétrospectives de manière plus efficace.
Avant le livre de Norm Kerth, nous ne connaissions que les autopsies. Ce sont des réflexions plus longues menées après que quelque selected a mal tourné. Les post-mortems sont très utiles comme outil pour apprendre des erreurs. Bien faites, elles peuvent avoir un effet curatif sur les personnes impliquées, mais ne sont pas les mêmes que les rétrospectives. On fait des rétrospectives, même si ça va bien. C’est pourquoi le sous-titre du livre de Derby Larsen est « – rendre les bonnes équipes formidables ».
Mais mon expérience pratique des rétrospectives m’a également montré à quel level une rétrospective peut facilement être inefficace. Si vous ne suivez pas l’idée d’une rétrospective et ne faites que passer par les étapes, vous perdrez du temps. En raison de la popularité des méthodologies agiles, les rétrospectives sont devenues très répandues. Ce succès est devenu un problème pour les rétrospectives. Tout le monde doit les avoir, mais ils ne passent pas le temps d’apprendre à les animer de la bonne manière. Cela a conduit à de nombreuses rétrospectives peu constructives, voire parfois nuisibles. Quand les gens prétendent que les rétrospectives sont une perte de temps, je suis souvent d’accord avec eux, quand j’entends remark ils font. Après quelques années, j’ai commencé à remarquer des modèles dans ce qui n’allait pas, également dans ceux que j’ai facilités.
Une histoire du Danemark
Une organisation avait décidé d’être plus agile dans sa façon de développer des logiciels. Dans le cadre de cela, ils ont introduit des rétrospectives comme moyen d’apprendre. Certains membres de l’équipe estimaient que les rétrospectives « gênaient » le « vrai » travail. Ils ont suggéré qu’ils pourraient être plus courts que les 90 minutes réservées pour eux. Comme l’animatrice n’était pas très expérimentée dans les rétrospectives, elle a décidé d’accepter.
Pour passer le moins de temps attainable, ils les ont raccourcis. Cela a eu de nombreuses conséquences négatives. Concentrons-nous sur un ici, un anti-modèle que j’appelle Roue de la Fortune. Dans une roue de fortune du monde réel, vous obtenez parfois un prix, et parfois vous perdez. Gagner ou perdre est aléatoire, et vous ne faites rien pour améliorer les possibilities. Cela peut également se produire lors de la rétrospective d’une équipe.
L’animateur a décidé d’utiliser l’activité populaire « Commencer, arrêter, continuer » pour recueillir des données. Mais pour gagner du temps, ils ont ignoré la génération d’insights, qui est l’un des les 5 étapes d’une rétrospective. Au lieu de cela, ils ont sauté de la collecte des données pour décider quoi commencer faire, que faire
arrêt faire, et que faire continuer motion.
Pour cette activité, l’animateur a posé trois affiches, une avec le mot « Begin », une avec « Cease » et une avec « Proceed ». Elle a ensuite demandé à l’équipe d’écrire des post-it et de les coller sur les affiches. L’une des notes disait « Démarrez la programmation en binôme », une autre « Arrêtez d’avoir autant de réunions ». L’équipe pourrait créer des factors d’motion à partir de ceux-ci : « Trois heures de programmation en binôme, trois jours par semaine ». Et « pas de réunions le mercredi et jamais de réunions après le déjeuner ». Et en 20 minutes, la rétrospective était terminée !
Cette façon d’organiser une rétrospective peut avoir des conséquences désastreuses. Si les post-it ne montrent que des options aux symptômes, pas les problèmes réels, vous ne pouvez réparer que la floor. Peut-être que la raison pour laquelle l’équipe n’a pas de programmation en binôme n’est pas qu’elle oublie, mais qu’il n’y a pas assez de sécurité psychologique. Dans ce cas, les pousser à le programmer dans le calendrier n’aidera pas. Soit ils ne le feront toujours pas, soit ils le feront et les gens se sentiront mal à l’aise et quitteront l’équipe, voire l’entreprise.
Une autre trigger de ne pas avoir de programmation en binôme pourrait être qu’ils ne savent pas remark le faire dans un environnement distant. Encore une fois, c’est un problème qui n’est pas résolu en mettant la programmation en binôme dans le calendrier.
Il en va de même pour la observe sur les réunions. Le problème avec les réunions pourrait être la qualité et non la quantité. Dans ce cas, avoir moins de réunions ne résoudra pas le problème, mais seulement le rendra moins évident. Lorsque les équipes demandent moins de réunions, c’est souvent amélioré hygiène de réunion qui peut résoudre le vrai problème.
Roue de la Fortune
Lorsqu’une équipe « résout » des symptômes au lieu de problèmes, les problèmes seront toujours là et ils réapparaîtront. Comme dans un vrai Roue de la Fortune ils pourraient avoir de la likelihood. Peut-être que certaines des choses qu’ils résolvent auraient pu être les vrais problèmes. Mais souvent, nous ne voyons que les symptômes et nous nous précipitons vers des « options » qui ne s’attaquent pas aux causes profondes. Le résultat est que même ces courtes rétrospectives semblent être une perte de temps, automotive c’est une perte de temps de discuter et de réagir uniquement aux symptômes.
Un anti-modèle doit avoir un resolution refactorisée, une description d’une resolution qui est meilleure que la resolution anti-modèle. Dans ce cas, la resolution refactorisée consiste à s’assurer de générer des informations avant de décider quoi faire. Avant de sauter aux conclusions. Vous pouvez le faire avec une easy dialogue sur les problèmes qui se posent. Ou avec un « 5 pourquoi » entretien. Si cela ressemble à un problème complexe, un analyse en arête de poisson pourrait être utile. Des exemples de problèmes complexes sont « manquer une échéance » ou « ne pas suivre le processus d’examen par les pairs ». Présentés ainsi, ils paraissent simples, mais la courte description cache une complexité : ces problèmes peuvent avoir de nombreuses causes différentes.
Dans la soupe
Lors de la rétrospective suivante, un autre anti-modèle est apparu. L’équipe voulait discuter de l’influence des logiciels pourris que leurs fournisseurs leur avaient fournis. La qualité de celle-ci était un problème fixed pour l’équipe. Leurs propres systèmes logiciels en étaient grandement affectés et ils avaient tenté de faire remonter le problème à la course. L’équipe en avait déjà discuté plusieurs fois. Chaque fois qu’ils en discutaient, ils étaient frustrés et tristes et rien ne changeait. Cela donnait l’impression que les rétrospectives étaient une perte de temps, automotive cela était une perte de temps pour discuter de choses qu’ils ne pouvaient pas changer. Ceci est un exemple de l’anti-modèle Dans la soupe.
Lorsque vous êtes dans la soupe, vous passez du temps sur des choses que vous ne pouvez pas améliorer. Au lieu d’apprendre et d’améliorer les problèmes, vous pouvez changer.
La resolution refactorisée consiste à utiliser une activité appelée Dans la soupe, où vous demandez à l’équipe de diviser les choses dont ils discutent en choses sur lesquelles ils peuvent faire quelque selected, choses sur lesquelles ils peuvent influencer et choses qui sont dans la soupe. Quand les choses sont dans la soupe, elles font partie de la vie que vous ne pouvez pas changer. Votre temps est mieux utilisé pour accepter et trouver un moyen de s’adapter à la scenario. Ou changer votre scenario en vous retirant de la soupe. Vous pouvez utiliser cette activité juste après avoir collecté les données comme indiqué ci-dessous. Ou vous pouvez l’utiliser lorsque vous décidez quoi faire afin de ne pas sortir de la rétrospective avec des factors d’motion qu’il n’est pas en votre pouvoir de mettre en œuvre.
Determine 1 : Choses que nous pouvons faire, choses que nous pouvons influencer, choses qui sont dans la soupe.
Grande gueule
Dans cette équipe, ils savent maintenant remark concentrer leur temps sur les choses qu’ils peuvent changer, et ils ont appris à quel level il est précieux de passer du temps à générer des idées. Mais ils ont encore un problème. Ils ont un
Grande gueule dans l’équipe. Dans toutes les discussions des rétrospectives (et dans toutes les autres réunions), cette grande gueule interrompt et raconte de longues histoires et rend inconceivable la participation des autres membres de l’équipe. L’animateur essaie d’inviter d’autres membres de l’équipe à s’exprimer, mais les choses ne changent pas.
Cet anti-modèle est quelque selected que l’on trouve souvent, mais il n’est pas difficile à résoudre. La première selected à savoir est pourquoi c’est un problème. Certaines personnes pourraient dire que si quelqu’un a quelque selected à dire, il devrait être autorisé à le dire, et je suis d’accord. Mais pour une rétrospective, le temps est réservé à une équipe pour partager, apprécier et apprendre ensemble. Et si seulement une partie de l’équipe est succesful de le faire, le temps peut être en partie perdu.
La resolution remaniée pour une équipe avec une grande gueule est de rester à l’écart des discussions plénières. Au lieu de cela, divisez les gens en petits groupes, voire en paires, pour discuter de sujets. Vous pouvez également introduire plus d’écriture et de déplacement de post-its au lieu de parler. Il peut même être bénéfique de parler à haute voix après la rétrospective. Ils ne sont peut-être pas conscients de l’effet qu’ils ont sur les autres, et souvent ils sont très reconnaissants d’apprendre cela sur eux-mêmes. J’ai travaillé avec des grandes gueules qui ont trouvé que cela changeait plus d’elements de leur vie d’être conscients de cette tendance. Certaines personnes sont ce que nous appelons des « penseurs actifs », et elles ont besoin de parler ou de faire quelque selected pour penser. Évidemment, ils ont besoin d’être bruyants lorsqu’ils réfléchissent, mais il n’y a pas de mal à cela.
Dans cet article, vous avez été présenté à trois des antipatterns les plus courants dans la facilitation rétrospective, et vous avez maintenant quelques trucs et astuces pour éviter d’être coincé dans l’un d’entre eux. Mais rappelez-vous que la compétence la plus importante qu’un facilitateur puisse avoir n’est pas de connaître beaucoup d’activités par cœur, mais d’écouter, d’utiliser son mind pour désamorcer le conflit et de continuer à réfléchir et à apprendre ce qui fonctionne pour lui.
