Rétrospective
L’entretien et l’évolution
Slack Facilité, 20 avril 2018:
« Hey gang! Petite question du vendredi: l’un de nos projets part en mode support v1/dev v2 avec 40 personnes au total et 6 max pouvant être dédiées au support v1. Dans vos expériences, qu’avez-vous mis en place en terme de répartition de l’équipe de support? On a déjà pensé à 5 équipes de dev (SCRUM) + 1 équipe de support et améliorations (KANBAN), 6 équipes (SCRUM) avec un membre de support dans chaque équipe ou une équipe de support qui tourne, d’autres idées? »
Mets-en que j’ai d’autres idées!
J’ai même d’autres questions. À quel moment dans notre histoire commune est venue l’idée de séparer l’entretien de l’évolution? Séparer le développement de nouvelles fonctionnalités du support de celles déjà livrées?
On s’entend que d’un point de vue Fordisme, cette division verticale du travail a beaucoup de sens. On peut même étendre ce raisonnement en amont, appliquer la même équation à la conception (architecture, design, analyse) et structurer le travail comme une bonne et belle chaîne de montage où chacun cogne sur son clou avant de passer le travail au suivant.
En ajoutant une belle matrice d’imputabilité, on peut même forcer chaque division à accomplir sa tâche, et uniquement sa tâche, de manière standard et mesurée.
Les 3 états d’une rétrospective
(English Follows)
Il est clair pour plusieurs experts Agile/Scrum que si vous ne devez appliquer qu’un seul élément de Scrum, vous devriez choisir de faire les rétrospectives. Cet acte simple et régulier de révision du processus et de la dynamique d’équipe est la fondation même de l’amélioration continue. Cet événement important n’est toutefois pas simple à animer, car étant donné que les gens parleront de leurs interactions et du travail de tous et chacun, le Scrum Master devra aider le groupe dans le développement de leur écoute et de leur communication.
En assumant que vous faites déjà ou que vous pensez faire de rétrospectives (rétro) de façon régulière, votre équipe Scrum va fort probablement être dans l’un des 3 états suivants :
Bruit / Efficacité / Stagnation
Bruit
Toutes les équipes que j’ai suivies sont passées par ces trois étapes. Les deux premières rétros sont toujours dans un état de Bruit où, pour la première fois, les gens ont la parole et peuvent défiler la liste de problèmes qu’ils gardaient pour eux. À ce moment, on vous parlera de la couleur du tapis, du manque de stylos bleus et de la machine à café. C’est normal, et c’est un moment critique où les gestionnaires/leaders pourraient, en posant les mauvais gestes, bloquer les canaux de communication avant même qu’ils n’aient le temps de s’ouvrir. Il est important d’accepter tous les commentaires, ou au moins de reconnaître le point de vue de chaque personne et la guider dans la résolution du problème.
Efficacité
Avec des rétros régulières, l’équipe va rapidement observer la résolution des bloquants mis en lumière pendant ces rétros. Cette réalisation, combinée avec la réduction du ‘Bruit’, va pousser l’équipe vers un état Efficace. Une fois dans cette mentalité, ils vont régulièrement identifier des points d’amélioration concrets qui vont aider l’équipe à comprendre l’importance de la boucle d’amélioration continue pendant qu’ils se résolvent systématiquement. Bientôt, la rétro est un événement attendu et le fait de négliger une rétro résulte en une sensation de déconnexion.
Stagnation
Comme Ed Catmull* a dit lors de sa présentation ‘Keep your crises small’ donnée à l’université de Stanford en 2007; ‘Le succès cache les problèmes’ et les gens on tendance à éviter de pointer des erreurs quand les choses vont bien. Aussi, une fois que l’équipe passe au travers d’une série de rétros ‘Efficaces’, les membres de l’équipe peuvent avoir une baisse de motivation, alors que leurs idées d’amélioration deviennent de plus en plus difficiles à trouver et que les gains diminuent. Quand cela se produit, la responsabilité de ramener l’équipe dans un état Efficace repose sur le Scrum Master. Cela peut être fait de différentes façons, mais ma solution préférée, que j’utilise systématiquement afin de prévenir la chute vers un état de Stagnation, est d’utiliser de façon périodique une rétro pour améliorer le produit plutôt que le procédé. Pendant ces ‘rétros spéciales’, je demande à l’équipe de trouver des points d’amélioration pour le produit en utilisant les mêmes plans de rétrospective utilisés dans les rétros normales. En plus de rafraîchir la perspective sur les procédés, ce truc augmente aussi l’engagement de l’équipe envers le produit.
*Président des studios d’animation Pixar et des studios d’animation Walt Disney
Phillipe Cantin
—
The 3 Stages of a Retrospective
Many Agile/Scrum experts agree that if you are only going to apply one part of Scrum, you should choose the retrospective. The simple and regular act of reviewing the team’s processes and dynamics is the foundation of continuous improvement. However, that important event is complicated to animate, and since people will be talking about their interactions and each other’s work, the Scrum Master will have to help the group as they develop their listening and communication skills.
Assuming you are either doing or planning on doing regular retrospectives (retros), your Scrum Team will most likely be in one of the following 3 stages:
Noise / Effectiveness / Stagnation
Noise
Every team I have followed went through those three stages. The first couple of retros are always in the Noise stage where, for the first time, people have the mike and are allowed to lay out the laundry list of problems they have on their mind. In the midst of that meeting, you will hear about the carpet color, the lack of blue pens and the coffee maker. It is a normal and critical time where managers/leaders could, through the wrong actions, block communication lines before they had a chance to open. It is important to accept all the feedback, or at least acknowledge the point of view of every person and guide them in the problem resolution.
Effectiveness
With regular retros, the team will soon witness the pragmatic resolution of different pain points they brought up at their retros. This realization combined with the reduction of the Noise will move the team toward an Effective state. Once in that mindset, they will regularly identify concrete improvement points that will help the team understand the importance of the continuous improvement loop as the points systematically get resolved. Soon, the retro becomes an expected event and skipping one creates a weird feeling of being out of touch.
Stagnation
As Ed Catmull* said in his ‘Keep your crises small’ talk at Stanford University in 2007; ‘Success hides problems’ and people have a tendency to avoid pointing out errors when things are going well. Also, once the team goes through a string of Effective retros, members can hit a motivational low point as their improvement ideas get harder to find and the gains get smaller. When that happens, it is the Scrum Master’s responsibility to bring the team back to an Effective state. It can be done in several ways but one of my go-to solutions, which I systematically use to prevent the team from slipping into the Stagnation state, is to periodically use one of the retros to improve the product instead of the process. During these ‘special retros’, I ask the team to find improvement points for the product using the same retrospective plans we use during normal retros. On top of refreshing the process perspective, this trick has the added benefit of improving the team’s engagement with the product.
*President of Pixar Animation Studios and Walt Disney Animation Studios
Phillipe Cantin
Rétrospective sur la collaboration
Récemment, je devais tenir une rétrospective dont le sujet principal était la collaboration entre trois équipes. On parle régulièrement de la collaboration au sein d’une équipe, mais force est de constater que la collaboration inter-équipes est un sujet qu’on aborde moins souvent.
J’ai donc parcouru internet à la recherche d’idées dans l’espoir que la rétrospective que j’allais tenir porte ses fruits.
Je suis tombé sur un article de blog publié par Renzo Venini sur le site de Scrum Alliance. Dans son article, M. Venini présentait une méthode basée sur des souhaits et des offres pour finalement converger vers des actions. Je vous laisse lire l’article original si vous souhaitez en savoir un peu plus sur sa technique.
Très intéressé par sa technique, j’ai tenté une approche afin que les équipes identifient leurs souhaits en considérant d’autres axes que ceux qu’ils emploient habituellement.
En me basant sur le Team Trust Canvas élaboré par Alexey Pikulev, j’ai créé un canvas identifiant les axes de collaboration inter-équipes.
J’ai détaillé ma version de la technique de rétrospective dans la section outils du site. Je vous invite à consulter la page correspondante par ici.
La rétrospective positive
Selon le guide Scrum, la rétrospective de sprint est « une occasion pour l’Équipe Scrum de s’inspecter et de créer un plan d’amélioration qui sera mis en place au cours du Sprint suivant. »
Au début de ma carrière de Scrum Master, je suivais cette définition assez rigoureusement. Cette rencontre était employée pour identifier nos problèmes et les régler. Cependant, en progressant dans ce rôle, j’ai remarqué que les gens devenaient fatigués d’être constamment mis au défi pour trouver des pistes d’amélioration. En creusant de plus en plus, on rencontrait des problèmes organisationnels ou professionnels qui ne pouvaient tout simplement pas être résolus. Cela minait l’humeur des gens. Curieusement, lorsque les commentaires restaient positifs à la rétrospective, l’équipe se dressait plus facilement un plan d’actions. Lorsque les gens se sentaient bien et fier d’eux-mêmes, ils travaillent plutôt à s’améliorer davantage.
J’ai aussi découvert que les rétrospectives positives se déroulaient mieux lorsqu’on utilisait un artéfact pour démarrer les conversations. Simplement démarrer la rétrospective en demandant aux participants de parler des aspects positifs du sprint était bizarre. Il fallait mettre la table, voir casser la glace.
Pour orienter les conversations positives, j’utilise habituellement deux outils: le calendrier niko-niko et le mood board. Le calendrier niko-niko est un outil bien documenté où on demande à chaque membre de l’équipe d’inscrire son état d’esprit général à chaque jour du sprint. On peut alors effectuer une rétrospective sur le niveau de bonheur de l’équipe à la fin du sprint.
Dans l’éventualité où un tel outil n’a pas été mis en place, je considère le mood board comme étant une bonne alternative pour démarrer des conversations positives. En somme, le mood board est un graphique où l’axe des X est la ligne du temps et l’axe des Y est le niveau de bonheur à travers le temps. Puisque ceci est un outil très scientifique, on peut remarquer que le niveau de bonheur maximal est le gros bonhomme Sourire dans la photo qui suit:
Il y a aussi des couleurs différentes pour illuster le parcours de chaque membre de l’équipe. Lors de ce projet, nous avons substitué plusieurs joueurs, d’où le début des courbes à différents moments. Une fois leurs courbes tracées, je demande aux participants dans la salle d’identifier des moments positifs en lien avec cet artéfact.
Dans la photo ci-haut, on remarque que le niveau de bonheur est à son plus bas aux itérations 5 et 6. Bien qu’on aurait pu s’enlisser dans les raisons qui nous amenées là, l’objectif de la rencontre était de rester positif. Les membres de l’équipe se sont donc mis à parler d’événements positifs qui les ont fait passer à travers cette période. Jean-Sébastien (ligne verte) a parlé de la venue positive de Martin #2 (ligne mauve). Et les conversations ont continué à être positives pour le reste de la rencontre.
Au final, aucun plan d’actions tangible n’est sorti de cette rencontre. Seulement de bonnes appréciations envers les membres de l’équipe. Et des fois, la reconnaissance par les pairs est ce qu’il faut discuter lors de la rétrospective d’équipe.
Excellence Agile 