Plusieurs mauvaises pratiques peuvent rendre une équipe moins efficace. D’abord faut-il être bien outillé pour les reconnaître. Les anti-patrons présentés dans cet article peuvent faire partie des habitudes actuelles que vous rencontrez. Dans cette deuxième partie, nous explorerons les anti-patrons qui rendent l’organisation du travail au sein de l’équipe de développement moins efficace et mettent en danger la réalisation du projet.
1. Pré-assigner les tâches
On peut être porté à croire que d’assigner le travail en début de sprint et spécialiser nos employés les rendra plus efficaces. Cependant, ça devient contre-productif lorsqu’une personne experte d’un sujet quitte l’équipe ou lorsqu’un développeur n’ose pas prendre l’item le plus prioritaire puisqu’il ne lui est pas assigné.
Il est préférable de laisser libre court à l’équipe quant à l’assignation du travail et de le faire au fur et à mesure. Rien n’empêche de nommer un référant expert. De cette façon on encourage la liberté, l’échange d’informations, le travail en paire, la libre circulation des items dans le système, on diminue les contraintes et on augmente l’efficacité.
Assigner un item par individu en début d’itération peut toutefois être une excellente idée, tant que cela est réalisé en équipe et avec l’accord de tous et chacun. Ainsi, on s’assure que les développeurs soient concentrés sur un item dès la première journée du cycle.
2. Ne pas limiter le travail en cours
Le meilleur moyen, pour rendre un système efficace, est d’obliger tous ses acteurs à se concentrer sur un nombre limité d’items à la fois. Lorsqu’on permet de travailler sur plusieurs items en même temps et qu’on ne met pas l’accent sur leur livraison, l’équipe s’éparpille et est moins efficace.
Limiter les “WIP” est une pratique bien ancrée dans Kanban, une méthode à flux tiré.
On priorise toujours l’ordre suivant dans un système à flux tiré:
- L’item le plus prêt de la livraison (ex: en cours de test)
- L’item bloqué
- L’item ouvert depuis le plus longtemps
3. Avoir des prévisions surchargées et irréalistes
Il arrive de prendre du retard dans un sprint et de terminer certains items au début du sprint suivant. Il est important de compter l’intégralité des points dans le sprint suivant, plutôt que de tenter de réestimer les items sur le travail restant, pour ne pas impacter la planification et fausser la vélocité. La vélocité est la moyenne du nombre de points relatifs complétés lors des dernières itérations.
De plus, il ne faut pas mettre plus de charge que l’équipe est capable d’en prendre et il faut aussi tenir compte du nombre d’items non pointés lors de la planification. Il est mieux, pour bâtir la confiance et respecter notre niveau de qualité, de sous charger une itération que l’inverse. Rien ne nous empêche d’ajouter un item lorsqu’on voit qu’on terminera l’itération en avance.
Finalement, on peut faire un parallèle au nombre d’items en cours (WIP). En respectant la cadence de l’équipe, on permet aux membres de l’équipe de se concentrer et de ne pas s’éparpiller sur plusieurs éléments à la fois. De plus, en amenant l’équipe à avoir une cadence de livraison d’items constante, on leur permet de se concentrer seulement sur le travail en cours. Un tableau Agile avec une quantité incalculable d’items nuit à la concentration.
4. Faire des rétrospectives où tout est parfait
Une rétrospective est un moment d’échange d’idées et l’occasion de trouver des plans d’action à mettre en œuvre pour s’améliorer. Une rétrospective, où tout ce qui est discuté est parfait et qu’aucun plan d’action en ressort, est une rencontre qui n’a pas atteint son objectif premier.
Aucune équipe ou processus n’est parfait, il y a toujours place à l’amélioration. Une façon plutôt efficace de faire jaillir de nouvelles idées est de varier les formats de rétrospective utilisés et de permettre d’avoir les conversations plus difficiles.
Par exemple, la gêne de dire ce qui ne va pas peut venir d’un climat de répression, d’un facilitateur qui n’est pas à l’écoute, d’un chef d’équipe qui se défend que le processus fonctionne, etc. La culture de l’échec et de l’amélioration continue, ça se travaille et ça émerge d’abord de l’écoute et de la volonté à s’améliorer.
Il est toutefois tout aussi important de profiter de l’occasion de la rétrospective pour faire ressortir les points positifs. Les bons coups des individus et les actions quotidiennes qui sont efficaces et rendent l’équipe plus performante.
5. Faire une itération de stabilisation
Une des valeurs à la base de l’Agilité est la transparence. Il est important de toujours exposer le travail qu’il reste à faire et de ne fermer les items qu’une fois qu’ils sont complétés et qu’ils respectent les standards de qualité.
Lorsqu’on essaie d’aller trop vite et de couper les coins ronds, on finit par se faire rattraper et c’est à ce moment qu’il devient tentant de faire une itération de stabilisation. Ce concept n’existe pas en Agile, il est plutôt préconisé de s’en tenir à l’essentiel et de livrer de la qualité.
Il est fréquent qu’une nouvelle fonctionnalité livrée en production génère des idées de modifications. Une pratique qui est plutôt efficace est de laisser un item d’amélioration dans le tableau de l’itération pour permettre au Product Owner d’y noter les idées d’amélioration et d’ensuite déterminer si les modifications peuvent être accomplies dans l’itération sans impacter l’objectif, au début de l’itération suivante ou si elles devraient plutôt être relayées dans une catégorie “post mvp” dans le carnet de produit. Il est aussi important, pour une équipe Scrum se fiant sur la vélocité, de pointer cet item d’amélioration avant de le débuter.
6. Apporter des ajouts d’urgence en cours de sprint
Une équipe Agile qui a choisi le cadre Scrum ne devrait pas être chamboulée à tout bout de champ par des urgences à ajouter dans l’itération. Ça devient contre-productif et vient fausser la vélocité de l’équipe ainsi que sa capacité à rencontrer sa prévision d’itération.
Si c’est une situation qui vous arrive très souvent, peut-être que le cadre Kanban serait plus indiqué à votre réalité. En kanban, on se fie surtout sur le nombre d’items réalisés (throughput), le temps de cycle et les probabilités pour effectuer des prévisions de livraison. La notion d’itération fixe et de chiffrage relatif ne fait pas partie des pratiques kanban.
En résumé
Pour terminer, les anti-patrons énoncés ci-dessus sont tout de même monnaie courante dans l’organisation d’une équipe Agile. Il fait partie de la culture de l’échec de se remettre sans cesse en question et de toujours tendre vers la perfection. Si plusieurs de ces situations s’appliquent à votre projet, rien ne sert de vous taper sur la tête, l’erreur est humaine. Maintenant que vous en êtes conscient, choisissez une action à prendre, celle qui paraît la plus prioritaire pour l’équipe et faites des tests. L’amélioration continue est aussi un processus itératif nécessitant de l’inspection fréquente et de la transparence.
