Suite de la série d’articles consacrée aux Agile smells, je vous propose, au travers de situations réellement vécues, de faire un tour d’horizon des dérives, des fausses bonnes idées ou simplement des phrases prononcées qui peuvent vous amener à vous dire que quelque chose sent mauvais. Aujourd’hui, parlons de la sprint rétrospective…
Si vous avez manqué un des épisodes de la série des Agile smells, vous pouvez les retrouver ici :
- Agile smells – Management visuel
- Agile smells – Sprint planning
- Agile smells – Sprint daily stand-up meeting
- Agile smells – Sprint review
« Merci Michel pour les croissants ! »
La situation
C’est la deuxième rétrospective de suite qu’au moment de recueillir les données, seulement cinq post-it se battent en duel. De plus ces post-it sont d’une utilité approximative, allant de « Ce soir c’est les vacances ! » à « Merci Michel pour les croissants ce matin ! ».
Pourquoi ça sent mauvais ?
Si la rétrospective ne sert plus qu’à faire de l’humour, c’est que vous vous êtes éloigné de son but initial. Bien que l’humour soit généralement le signe d’une équipe qui s’entende bien, cette situation cache un problème qui peut être :
- La routine : l’équipe a déjà effectué des dizaines d’itérations, il se forme une certaine routine accompagnée de lassitude. Les personnes ne font alors plus vraiment d’effort pour essayer de s’améliorer.
- Je vais bien, tout va bien : tout va pour le mieux, l’équipe avance sans rencontrer de véritable problème, elle a du mal à trouver des axes d’amélioration. Il est effectivement toujours plus facile de corriger quelque chose qui fonctionne mal plutôt que d’améliorer quelque chose qui fonctionne déjà bien.
- Le sentiment d’inutilité : les éléments remontés lors des précédentes rétrospectives n’ont toujours pas été résolus ou améliorés, l’équipe finit par ne plus croire en l’utilité de cette cérémonie.
- Alzheimer : un syndrome plutôt répandu chez pas mal de personnes qui ont tendance à oublier ce qu’il s’est passé durant les deux ou trois dernières semaines.
Concrètement on fait quoi ?
La rétrospective est une brique essentiellement de l’amélioration continue de l’équipe. Pour ceux qui souhaitent se rafraîchir les idées sur le déroulement idéal d’une rétrospective, je vous conseille de lire Donnez du peps à vos rétrospectives.
Quelques pistes pour aller plus loin :
- Contextualiser
Chaque itération est unique, avec son propre lot d’événements. S’il s’est passé beaucoup d’événements durant l’itération ou si au contraire il n’y en a eu qu’un seul mais important, si l’ambiance est au beau fixe ou s’il y a des tensions, il faut savoir adapter le format de la rétrospective pour qu’il soit le plus pertinent possible par rapport au contexte. Nous reviendrons plus en détail sur ce sujet dans un futur article « Quelle rétrospective pour quelle itération ? ».
- Varier
Bon nombre d’animateurs se contentent de jouer avec un, voire deux formats simples de rétrospective. Bien que cela suffise au début de la vie du projet, les membres de l’équipe étant tous motivés et ayant des choses évidentes à améliorer, cela peut vite entraîner une certaine lassitude. Au delà du fait de contextualiser chaque rétrospective, il est également important de connaître plusieurs formats répondant à une même situation afin de casser la routine.
- Tourner
Il existe plusieurs rôles plus ou moins utilisés : facilitateur, timekeeper, observateur et pousse décision. Les attribuer en début de rétrospective est un bon moyen de garantir la concentration des personnes durant la cérémonie. Les faire tourner à chaque itération, y compris celui du facilitateur, est également intéressant pour insuffler un renouveau dans votre rétrospective. Attention toutefois avec le facilitateur, tout le monde n’est pas forcément en capacité d’assumer ce rôle.
- Anticiper
Certaines personnes ayant régulièrement du mal à se souvenir de ce qui leur est arrivé durant l’itération, il peut être utile de leur présenter le format de rétrospective un ou deux jours avant la rétrospective afin de leur laisser plus de temps pour se remémorer les évènements. Mieux, les accompagner pour leur faire prendre des notes tout au long de l’itération afin de ne pas les oublier le jour j, via l’activité Empty the mailbox par exemple, est la garanti d’avoir du contenu de qualité.
- Evaluer
Si la rétrospective devient rébarbative, il faut le demander. Après chaque cérémonie, la faire évaluer et demander comment l’améliorer est le meilleur moyen de répondre, à terme, aux attentes de tout le monde.
« Communiquer mieux »
La situation
Les actions qui sont prises par l’équipe à la fin de la rétrospective sont du type « Communiquer mieux », « Être plus rigoureux » ou « Faire plus de binômage ».
Pourquoi ça sent mauvais ?
Lorsque des personnes se plaignent de manière récurrente d’une faible qualité de code ou d’une baisse constante de la couverture de code, le réflexe simple est de penser qu’il s’agit d’un soucis de rigueur. Si les gens font attention, il n’y aura plus de soucis et l’action « Être plus rigoureux » sera suffisante puisque tout le monde a hoché la tête fièrement en se disant que c’était évident. Dans la réalité, ces phrases que l’on espère magiques ne règlent absolument rien et vont rendre la rétrospective lassante sur le moyen terme car les mêmes problèmes seront continuellement remontés.
« Communiquer mieux » ou « Être plus rigoureux » ne sont pas des actions mais plutôt des lignes de conduite.
Concrètement on fait quoi ?
En premier lieu, il faut constamment avoir en tête un principe simple souvent appliqué aux actions de rétrospective : elles doivent être SMART. Hormis la partie sur la temporalité, qu’il est préférable de définir au maximum à une itération, ces grands principes sont à garder en tête et doivent servir à valider qu’une action est bel et bien une action. Bien évidemment, s’il ne fallait en garder qu’un, ce serait le fait d’être mesurable : associer des indicateurs à une action est le meilleur moyen de savoir si elle est terminée ou non.
Reprenons les exemples cités précédemment et transformons les en exemples d’actions associées :
- Communiquer mieux : organiser un point de synchronisation avec un représentant de chaque équipe tous les mardi et jeudi à 11h afin de partager les informations transverses.
- Être plus rigoureux : mettre en place un outil de contrôle de code afin de s’assurer que l’équipe a le même style d’écriture.
- Faire plus de binômage : identifier 2 stories durant le sprint planning pour lesquelles l’équipe devra obligatoirement faire du pair programming.
Pour arriver à la génèse d’une action digne de ce nom, il ne faut donc pas s’arrêter à la surface du problème mais investiguer. Si l’on ne devait retenir que deux techniques permettant de le faire, ce pourrait être :
- Les cinq pourquoi : Répéter la question « Pourquoi ? » à chaque réponse apportant une raison.
- Le QQOQCCP : Définir les « Qui ? », « Quoi ? », « Où ? », « Quand ? », « Comment ? », « Combien ? » et « Pourquoi ? ».
« Et cette action ça fait 3 itérations, on la garde ? » – « Oui c’est vraiment bloquant ! »
La situation
Voilà plusieurs itérations qu’une action de rétrospective n’est pas mise en oeuvre. À chaque début de rétrospective, l’équipe décide de garder cette action car le problème sous jacent est considéré comme trop important.
Pourquoi ça sent mauvais ?
De manière évidente, engager des actions qui ne sont pas tenues ne sert pas à grand chose et peut même nuire à l’équipe sur le long terme. Plusieurs raisons peuvent expliquer ce problème :
- Action trop grosse : une action engageant un changement radical de processus, la mise en place intégrale d’un outil ou le refactor de toute une batterie de test va à coup sûr être impossible à réaliser au terme d’une seule itération.
- Action diluée dans la masse : s’il y a trop d’action à mener, l’équipe risque d’avoir du mal à les mener toutes à bien.
- Action non suivie : si les actions ne sont suivies par personne, elles ont vite fait de tomber dans l’oubli car l’équipe sera occupée à traiter d’autres sujets pendant l’itération. Ce n’est que lors de la rétrospective suivante qu’elle se rappellera des actions qu’elle aurait dû mener.
Concrètement on fait quoi ?
L’objectif de la rétrospective est d’aboutir à une liste d’actions qui, une fois réalisées, vont permettre à l’équipe de s’améliorer. Quelques règles simples à appliquer :
- Spécifier
Lorsque l’équipe arrive à la conclusion qu’il lui faut créer un outil pour résoudre ses soucis, l’action ne doit pas être de créer l’outil mais plus d’alimenter le backlog avec les stories de cet outil. Créer l’outil idéal ne se fait pas en une itération, créer des stories oui. Le suivi de l’avancement des développements de l’outil ne se fera donc pas via la rétrospective mais via le backlog, comme pour les stories du produit.
Ce même principe peut être appliqué dans le cas de refactor trop important ou de processus. Pour ce dernier, si les tensions remontées se situent avec une autre équipe, changer la manière dont interagissent les deux équipes ensemble ne se fera pas en une itération. L’action pourrait être de monter une réunion avec l’autre équipe. Le suivi du résultat de cette réunion se faisant en dehors de la rétrospective.
- Mesurer
Une action doit représenter un moyen d’arriver à un objectif et doit par conséquent être mesurable. Lorsque l’action est définie, elle doit obligatoirement être accompagnée d’une DOD (Definition of Done) qui donne des éléments mesurables permettant de savoir que l’action a été terminée.
- Prioriser
Si votre rétrospective aboutie sur trop d’actions, sélectionner en équipe les deux ou trois plus prioritaires. Mieux vaut deux actions terminées que six en cours.
- Suivre
Pour suivre les actions il suffit de deux choses : désigner un responsable, pas forcément celui qui réalisera l’action mais plutôt qui fera en sorte que les gens se mobilisent pour que l’action soit réalisée, et faire en sorte que le tableau de suivi des actions soit visible en daily stand up meeting de manière à suivre leur avancement quotidiennement.
Evitons au passage de tomber dans un autre smell : il ne doit pas y avoir un unique responsable pour toutes les actions (on retrouve souvent le cas du Scrum Master qui gère tout) mais plutôt un responsable différent par action.
- Nettoyer
Si une action stagne d’itération en itération, il suffit de la supprimer. Le besoin a dû changer, disparaître ou n’est simplement plus vraiment prioritaire sinon l’action aurait été menée. Dans le pire des cas, elle émergera d’une future rétrospective.
« Si l’autre Michel se bougeait un peu, on pourrait peut être y arriver… »
La situation
Lors de la rétrospective, une personne nomme spécifiquement quelqu’un comme étant le responsable de l’échec d’une tâche, d’une itération ou d’une release.
Pourquoi ça sent mauvais ?
Ce qui peut ressortir de cette situation :
- Une personne est en conflit avec une autre et l’exprime publiquement
Le conflit étant ouvert sur la place publique, en laissant une telle situation perdurer il y a un risque de contamination sur les autres membres de l’équipe. Des collègues sont forcément pris à partie et doivent se positionner, ce qui va forcément décevoir un des deux protagonistes. La résultante est un climat délétère au sein de l’équipe.
- Un bouc émissaire
L’équipe a un coupable tout désigné pour chaque problème qu’elle rencontre. Cela cache souvent une incapacité à se remettre en question et une tendance à fuir ses responsabilités.
- Certaines personnes ont l’habitude de chercher des coupables au moindre problème
Le problème avec ce genre de situation est qu’elle entraîne une défiance de la part des personnes au moment de participer à la rétrospective. La moindre erreur sera forcément mal vécue par son auteur par peur d’être pris pour cible. Il y aura forcément moins d’initiative et de prise de risque, et plus de stress au sein de l’équipe.
Concrètement on fait quoi ?
Lorsqu’un conflit entre deux personnes éclate publiquement, il est nécessaire de le traiter au plus tôt. La rétrospective n’est pas l’endroit le plus adapté pour cela, il est préférable de passer par un entretien directement avec les personnes concernées pour gérer ce conflit.
Dans tous les cas, introduire chaque rétrospective avec le principe suivant : « Indépendamment de ce que nous allons découvrir aujourd’hui, nous comprenons et nous croyons vraiment que chacun a fait de son mieux, en fonction de ses connaissances, de ses compétences et de ses capacités, des ressources disponibles et de la situation courante. » (Norm Kerth). L’idée derrière cela est d’inciter les gens à émettre des critiques constructives plutôt qu’à blâmer.
Le rôle du facilitateur de la rétrospective devient primordial ici. Au delà d’un simple principe énoncé en début de cérémonie, il doit être réactif dès qu’une accusation est portée :
- en demandant de reformuler la critique sans citer explicitement quelqu’un
- en essayant de remonter aux origines du problème (via la technique des « cinq pourquoi » par exemple)
- en demandant ce que l’équipe (plutôt que la personne accusée) aurait pu faire pour éviter l’erreur
Être attentif à tout signe d’accusation ou de jugement et les traiter, permet d’instaurer des habitudes dans la manière d’aborder la rétrospective pour chaque membre de l’équipe.
Conclusion
Au travers de quatre situations, nous avons découvert comment la rétrospective pouvait révéler des pratiques contre productives, mais également, comment il pouvait être une aide d’une grande efficacité pour améliorer de nombreux aspects de la vie d’une équipe. Ne jetez pas votre désodorisant tout de suite, nous revenons bientôt avec de nouveaux agile smells dédiés cette fois-ci au backlog et user stories.