Get best of the week

Antipatterns de rétrospective dans l'équipe Agile. Partie 1

J'ai récemment calculé que pendant plusieurs années en tant que Scrum Master, j'ai passé plus de 100 rétrospectives dans des équipes Agiles. Je veux parler de l'importance de la rétrospective et comment elle reflète la situation dans l'équipe et affecte son développement, dans cet article.



Quelques mots sur moi. Depuis 2015, je me concentre sur la constitution d'équipes Agiles heureuses et efficaces dans des entreprises internationales. De plus, j'aime faire de la formation interne. En plus du travail principal avec l'équipe, j'enseigne les Scrum Masters à l'école et mène des formations dans les domaines des tests Agile / Scrum / Agile. 

Depuis le début de ma carrière de Scrum Master, j'ai eu la chance de travailler directement avec 10 équipes très différentes et intéressantes. Chacun d'eux s'est développé à son rythme unique et pourtant ils avaient quelque chose en commun - la qualité des rétrospectives a grandement influencé l'efficacité globale de l'équipe. En même temps, j'ai remarqué que, dans n'importe quelle équipe, la rétrospective cesse tôt ou tard de fonctionner. Quelque chose se passe et cet outil d'inspection et d'adaptation le plus populaire tombe en panne, c'est-à-dire cesse d'aider l'équipe à s'adapter et à s'améliorer.

J'ai systématisé mes observations et voudrais partager les 5 principaux antipatterns que j'ai rencontrés dans mes équipes. 

Dans chaque antipattern, je veux discuter:

  • signes et causes d'un certain comportement;
  • que faire Scrum au maître et à l'équipe pour corriger la situation.

Dans la première partie de l'article, je parlerai de trois antipatterns. Dans la deuxième partie, je partagerai des observations sur deux autres antipatterns, ainsi que mes recommandations: ce que les Scrum Masters et les équipes peuvent faire de manière proactive, c'est-à-dire à l'avance, avant même que le comportement décrit dans l'article n'apparaisse, de sorte que la rétrospective continue de fonctionner et d'être un outil efficace pour l'amélioration de l'équipe.
 

Antipattern n ° 1 "Tout va bien avec nous"




L'équipe tient une rétrospective, mais la considère comme une formalité. L'anti-modèle se manifeste dans le fait que l'équipe, en principe, décide de ne pas mener de rétrospective (pas de problème, tout va bien - pourquoi se réunir?). Mais dans ma pratique, ce cas était extrêmement rare et le rejet de la rétrospective était dicté plutôt par d'autres raisons. J'écrirai un article séparé à leur sujet plus tard. En attendant, revenons à la façon de reconnaître cet antipattern.

Signes et raisons:

L'équipe se rassemble, ouvre rétrospectivement le modèle d'activité standard (fou / triste / content ou commence / arrête / continue), écrit les principaux aspects positifs de l'itération et après 20-30 minutes diverge sans discuter des problèmes et du plan d'amélioration de l'équipe. L'équipe évite de parler de problèmes ou convainc le Scrum du Maître et les uns des autres qu'il n'y a tout simplement aucun endroit où s'améliorer.
Quelle pourrait être la raison de ce comportement?

  • Les gars peuvent croire sincèrement que tout va bien avec eux: ils livrent le produit, le propriétaire du produit est satisfait, que faut-il d'autre?
  • C'est une équipe super cohésive qui travaille ensemble depuis longtemps et ne peut imaginer comment vous pouvez devenir encore meilleur, car tout le monde dans l'entreprise est égal à eux.
  • J'ai rencontré des équipes dont les membres pensaient que tous les problèmes existants qui se trouvaient dans la zone de contrôle ou d'influence de l'équipe avaient déjà été corrigés, et l'équipe n'avait toujours rien à voir avec d'autres problèmes, à quoi bon perdre du temps et en discuter à nouveau. Pour de tels problèmes, j'ai même obtenu un terme - "entreprise donnée".

Que faire:

Dans cette histoire, pour moi, cela dépend beaucoup de la façon dont je, en tant que Scrum Master, pense que tout va bien dans l'équipe, ou j'ai des doutes à ce sujet.

Si vous avez le sentiment que tout va très bien dans l'équipe, vous pouvez procéder comme suit:

- Offrir à l'équipe rétrospectivement une question complexe qui sort de la zone de confort. Par exemple, «ce que nous, en tant qu'équipe, pouvons proposer pour offrir 10 fois plus de fonctionnalités qu'aujourd'hui, en même temps». Ou "comment pouvez-vous complètement vous éloigner de l'exécution manuelle de la régression". Pour certaines de mes équipes, la deuxième question semblait encore plus inadéquate que la première.

La première réaction à cette question sera probablement une stupeur et une surprise, mais la prochaine étape peut être un brainstorming intéressant, un regard sur le système dans son ensemble et des idées intéressantes pour optimiser l'ensemble du processus de livraison de valeur.

- Profitez de l'occasion pour les membres de l'équipe de mieux se connaître et de stimuler le travail d'équipe à travers les jeux. Je ne m'attarderai pas sur le thème des jeux, je peux seulement dire qu'il existe de merveilleuses activités pour travailler avec les valeurs de Scrum, pour se concentrer sur un objectif commun, pour renforcer la confiance dans une équipe. Il existe de nombreux formats de jeu décrits dans les sources ouvertes. À propos de ceux que j'ai dirigés, je les partage dans mon blog professionnel Scrum Masters.

Bien sûr, les jeux ne doivent pas être complètement remplacés par des rétrospectives, mais ils peuvent devenir un «répit» pour l'équipe, une opportunité de changer le contexte de travail et de regarder l'efficacité du travail d'équipe d'autre part.

Et pourtant, que faire Scrum au Maître, s'il n'y a pas cette confiance intérieure que tout va bien? Pour ce cas, j'ai deux idées.

La première consiste à élargir le contexte rétrospectif de l'équipe, c'est-à-dire élargir l'angle de vue sur la situation dans l'équipe. Par exemple, cela peut être réalisé en ajoutant de nouveaux participants à la rétrospective. J'ai vu beaucoup d'équipes qui ont mené des rétrospectives sans la participation du propriétaire du produit en raison de diverses circonstances (il ne voulait pas, donc historiquement, une barrière linguistique). Pour ces équipes, une rétrospective avec la participation du propriétaire du produit aura lieu d'une manière complètement nouvelle. La même idée peut être réalisée en invitant des membres d'autres équipes liées qui sont en avance ou après l'équipe dans la chaîne d'approvisionnement de valeur. Un détail important - tout cela doit être fait avec le consentement de l'équipe, l'invité invité, comme surprise, apportera probablement douleur et méfiance au Scrum Master, plutôt que d'aider à établir une rétrospective.

La deuxième idée est d'offrir Scrum au Maître ou à l'un des membres de l'équipe pour collecter des données qu'ils n'avaient jamais collectées auparavant. J'ai un merveilleux exemple dans mon expérience lors de l'analyse des statistiques collectées sur le nombre de défauts trouvés à l'intérieur du sprint (à savoir, la tendance de cette métrique au cours des 4 derniers sprints) a conduit l'équipe à des discussions très productives sur la façon d'améliorer la qualité des tests chez les développeurs et comment organiser une interaction étroite entre les tests et développement à l'intérieur du sprint. Il arrive souvent qu'en général, l'équipe se débrouille bien à la fois dans ses sentiments et dans les retours de l'extérieur, mais il y a encore beaucoup de points à améliorer, il suffit d'attirer l'attention de l'équipe sur eux.

Antipattern n ° 2 «Noah, nous nous plaignons, il n'y a pas de plan»




L'histoire est que l'équipe vient facilement à la rétrospective pour se plaindre, ressentir, pleurer, pleurnicher, mais il n'y a pas de plan pour travailler avec des problèmes, comme un plan d'amélioration, à la suite de la rétrospective. Plus précisément, l'équipe a un plan, un ensemble d'actions a été élaboré, il y en a des responsables, mais ce plan n'aide pas vraiment l'équipe à s'améliorer, n'aide pas à mettre en place des expérimentations et à tester des hypothèses afin d'augmenter l'efficacité du travail ou d'améliorer la qualité du produit. Ce plan est plutôt une formalité, un plan pour le bien du plan.

Panneaux:

  • L'équipe discute vigoureusement de ce qui se passe dans l'équipe, mais il n'y a pas assez de temps pour le planifier, et cela diverge jusqu'à la prochaine fois, au mieux, avec une liste de ce avec quoi elle prévoit de travailler un jour. La question de savoir exactement qui, quand et comment fonctionnera reste ouverte.
  • , , , , : , - , .
  • , , 80-90% – , , , . , , . , ( , , ) , .

Voyons comment vous pouvez travailler avec ces situations.

Que faire:

commençons dans l'ordre. Pour que le plan d'amélioration apparaisse dans l'équipe, tout d'abord, il est nécessaire que l'agenda rétrospectif (à savoir, toutes ses phases - enregistrement, collecte d'idées, analyse des idées, élaboration d'un plan d'amélioration, achèvement et retour d'informations) soit transparent pour l'équipe et qu'il y ait du temps pour l'élaboration d'un plan d'action. J'ai eu des cas où nous n'avions pas eu le temps d'élaborer un plan d'action en profondeur, puis j'ai nommé une session distincte pour terminer la rétrospective et formuler un plan. Je pense qu'il vaut mieux étendre le temps alloué à la rétrospective que de le terminer à temps, mais sortir sans résultats.

S'il y a des problèmes dans l'équipe pour s'adapter à l'heure prévue de la réunion, il existe une approche pour régler plusieurs minuteries, par exemple pour 15, 8 et 5 minutes. Dès le début, l'équipe sait que la discussion devrait se terminer à la fin de la troisième minuterie et est davantage axée sur la négociation. En général, les techniques de facilitation, l'organisation du travail en petits groupes et un temps fixe pour les discussions et les phases individuelles des travaux rétrospectifs font merveille et contribuent à conduire au développement de solutions même pour des groupes aux dynamiques complexes.

Alors, que devrait faire Scrum au Maître si l'équipe ramène rétrospectivement les problèmes d'organisation et évite les vrais problèmes? Il y a plusieurs outils qui, selon mon expérience, ont aidé:

  • – – , , , , « , ».
  • , (, ). , . , , .
  • , , , , , . . , , - .
  • , , , , . , !

№3 « , »




Le nom parle de lui-même - un plan a été élaboré pour l'équipe, mais les actions ou expériences inventées ne sont pas effectuées.

Signes: Les

signes d'anti-motif sont assez évidents - dans la prochaine rétrospective, l'équipe n'a rien à partager comme résultats de la mise en œuvre d'actions ou d'accords précédemment pensés. Tout le monde, bien sûr, a de bonnes raisons - il n'a pas eu le temps, ses mains n'ont pas atteint, il était engagé dans des affaires plus importantes, a-t-il oublié. Mais grâce aux progrès en termes d'améliorations et d'expériences, non.

Parlant de cet anti-modèle, je veux m'arrêter sur les «appels dérangeants» au stade de la compilation du plan, qui dans ma pratique étaient le plus souvent des signaux que les actions du plan ne seront pas effectuées:

  • action items (.. ) «, , ». , , .
  • , , . , , « unit ». , , , « », « », , . «, , » .
  • , : «, , , wiki , », « / , , », «, 3 , , , », « , , , »

Que fais-je dans une situation où des plans apparaissent dans mon équipe qui sont écrits mais pas faits? Je me souviens que si les gens ne font pas quelque chose, il peut y avoir les raisons suivantes:

1. Je ne comprends pas
2. Je ne peux pas
3. Je ne peux pas
4. Je ne veux pas

Cette pensée m'aide beaucoup à m'arrêter et à penser s'il est possible d'exclure des options "Je ne comprends pas, je ne peux pas, je ne sais pas comment", avant de commencer à travailler dans le domaine "Je ne veux pas" et de gérer la motivation de la personne, pourquoi est-il dans l'équipe et quels sont ses objectifs.

Que faire?

Voyons ce qui peut être fait exactement, en fonction de la raison de l'inaction.

Raison 1: un membre de l'équipe qui a accepté d'entreprendre une action ne comprenait vraiment pas ce qu'on attendait de lui.

  • , .
  • , , , , .
  • , , , - . 

Raison 2: un membre de l'équipe et serait heureux de remplir le point d'action qu'il a pris sur lui-même, mais physiquement ne peut pas le faire, car occupé avec d'autres tâches et il n'a pas le temps pour cela dans le sprint.
 
Scrum Master peut ajouter l'activité la plus importante du plan de la rétrospective au backlog de sprint (après en avoir convenu avec le propriétaire du produit sur le rétro ou après), l'évaluer, noter qui le fera, rendre transparent pour tout le monde que l'équipe passera du temps à ce sujet. 

Raison 3: le membre de l'équipe serait à nouveau heureux de réaliser ce pour quoi il s'est inscrit car c'est vraiment intéressant et important pour lui (par exemple, choisir le cadre le plus approprié pour les tests de résistance), mais il n'a jamais traité cela auparavant et n'a jamais peut comprendre par où commencer. C'est là qu'il finit, car il peut être désagréable d'expliquer à l'équipe pourquoi il a pris cette activité s'il ne sait pas comment.

Scrum Master peut vérifier auprès de quelqu'un qui est prêt à entreprendre l'activité dans le cadre du plan rétro, s'il devait faire quelque chose comme ça avant. Sinon, il est certain qu'il y a quelqu'un dans l'équipe plus expérimenté dans ce domaine qui pourrait vous aider. Et si toute l'équipe n'a pas d'expertise dans le domaine, le Scrum Master peut se charger de rechercher des experts dans d'autres équipes ou dans la communauté.

J'ai une autre pratique de bonus, qui aide vraiment l'équipe à réaliser le plan - suspendez les activités du plan à un endroit bien en vue pour l'équipe. Idéalement, chaque membre de l'équipe qui a pris une sorte d'activité a emporté un autocollant avec ce À FAIRE pour l'accrocher à un endroit bien en vue sur le bureau et ne pas l'oublier. Ils disent que si le but est devant les yeux, une personne y va consciemment et inconsciemment. J'aime beaucoup plus cette approche que de rappeler régulièrement à l'équipe que le rétro approche et mérite d'être rafraîchi en mémoire de ce que le plan était la dernière fois.

J'ai donc partagé mes réflexions sur les trois premiers antipatterns de la rétrospective dans les équipes Agile que j'ai rencontrées dans ma pratique, et il y en a deux de plus, non moins intéressants et non moins communs.

Je serai heureux d'entendre vos histoires et vos observations sur les rétrospectives qui fonctionnent et qui ne fonctionnent pas. Dites-nous quelles techniques et techniques vous avez pour construire des rétrospectives efficaces. Vous devinez de quels antipatterns je compte parler dans la suite?
 

More articles:


All Articles