Vous en avez assez des rétrospectives “classiques” qui ne semblent pas toujours apporter les améliorations souhaitées ? Au travers de cette traduction enrichie, découvrez comment Benji Huser-Berta et son équipe ont réinventé l’art de l’inspection et de l’adaptation en adoptant une approche d’amélioration continue au quotidien. Plongez avec nous dans cette transformation passionnante et découvrez les avantages et les défis qu’ils ont rencontré en cours de route.
Agilité sans frontières : au-delà des rétrospectives cadencées
Il est temps de briser les chaînes des rétrospectives traditionnelles. Si les rétrospectives ont leur place, elles ne sont pas la seule manière d’inspecter et d’adapter votre équipe. En effet, le Manifeste Agile énonce l’un de ses douze principes comme suit :
À intervalles réguliers, l’équipe réfléchit sur la manière de devenir plus efficace, puis ajuste et adapte son comportement en conséquence.
Quelle que soit la méthode que vous utilisiez – Scrum, LeSS, Kanban, SAFe, ou une approche personnalisée – l’important est de réfléchir régulièrement sur la manière dont votre équipe travaille et comment elle peut améliorer son efficacité.
L’évolution vers l’amélioration continue : de la cadence à l’immédiat
La définition de la folie, c’est de faire la même chose encore et encore et de s’attendre à un résultat différent.
De la cadence à la continuité
Notre équipe a commencé par des rétrospectives basées sur une cadence, comme beaucoup d’autres.
Nous menions nos rétrospectives toutes les 4 semaines. Ces rétrospectives étaient généralement engageantes et nous parvenions à trouver des éléments d’action concrets qui avaient généralement un impact positif sur notre manière de travailler.
Cependant, quatre semaines, c’est long. Et bien que l’équipe soit satisfaite de nos rétrospectives, nous avions le sentiment que nous passions à côté de certaines discussions précieuses. Tout le monde était encouragé à signaler des obstacles ou des améliorations potentielles à tout moment, mais nous n’en recevions pas autant “entre” deux rétrospectives.
Ainsi, nous avons vite réalisé qu’il y avait des moyens plus adaptés à notre contexte pour réfléchir à notre efficacité.
Analyse des causes profondes
Les rétrospectives n’étaient cependant pas le seul moyen par lequel nous réfléchissions à nos méthodes de travail. Pour chaque problème signalé par un client, nous menions une analyse des causes profondes (ACP dans la suite de l’article)… et les occasions d’apprendre étaient nombreuses : nous étions confrontés à une importante dette technique et de problèmes de qualité liés qui s’étaient accumulés au fil du temps. Nous avions donc de nombreuses opportunité d’apprendre, de réfléchir et de nous améliorer.
Apprendre de chaque élément du backlog : un nouveau paradigme pour l’amélioration continue
En constatant l’impact positif de l’analyse des causes profondes sur la résolution des problèmes de nos utilisateurs, nous avons décidé d’étendre cette approche à l’ensemble de notre processus. Ainsi, nous avons intégré la notion d’apprentissage dans notre définition du flux de travail, créant un environnement où chaque élément du backlog est l’occasion de grandir et de s’améliorer.
Mener une ACP pour chaque problème remonté a contribué à améliorer considérablement la qualité. Trouver des schémas dans les causes profondes des problèmes nous a aidés à résoudre les problèmes les plus importants.
Cela a pris du temps, mais avec le temps, nous avons constaté une amélioration significative… et surtout, surtout, surtout cela signifiait aussi que nous ne réfléchissions plus aussi souvent.
Réfléchir aux apprentissages pour chaque élément du backlog
Comme nous avons constaté l’effet positif de notre ACP sur les problèmes des clients, nous avons pensé qu’il serait judicieux de le faire plus fréquemment et de l’appliquer de manière plus large à notre processus.
Ajustement du flux de travail
Nous avons introduit la saisie des apprentissages dans notre flux de travail. Le terme a été choisi volontairement plutôt que “Analyse des causes profondes”, car nous ne voulions pas nous limiter. Nous pouvons apprendre des bogues comme des nouvelles fonctionnalités. Nous pouvons apprendre des choses qui ne se sont pas bien passées ainsi que des éléments qui se sont très bien déroulés.
En fin de compte, cela signifie que pour chaque élément sur lequel l’équipe travaille, nous voulons saisir ce que nous avons appris et comment nous pouvons nous améliorer en tant qu’équipe.
En pratique, cela signifie que, pour chaque élément de Capture Learnings, nous avons une discussion sur ce que nous avons appris. Chacun est invité à y contribuer. Souvent, nous demandons spécifiquement aux personnes ayant traité le sujet de partager leurs apprentissages. Cela se fait de manière asynchrone via notre outil de discussion inerne.
Il existe plusieurs résultats possibles de cette discussion :
Pas d’apprentissage exploitable
L’élément est clôturé. Il est important de noter qu’il n’est pas obligatoire de générer quelque chose pour chaque élément.
Apprentissage exploitable qui peut être réalisé immédiatement
Faites-le, puis fermez l’élément une fois qu’il est terminé. Cela pourrait être quelque chose de tangible comme des modifications de code/wiki ou moins tangible comme des discussions avec l’équipe ou la tenue d’une session de partage des connaissances.
Apprentissage qui nécessite plus d’efforts
Créez un élément de suivi, liez-le à celui qui a suscité la discussion et clôturez-le. Il est important de noter ici que nous visons à travailler sur l’élément de suivi bientôt (dans les semaines à venir). Les éléments qui sont des “choses intéressantes à faire dans 6 mois” ne sont pas ce que nous recherchons.
Apprentissage qui nécessite plus de discussion
Ici, nous retrouvons typiquement les sujets que nous aimons aborder en rétrospectives : Plus en détail ou avec un public plus large (avec toute l’équipe ou des personnes en dehors de l’équipe). Clôturez l’élément après la discussion et suivez avec d’autres actions si nécessaire.
Les conséquences de l’amélioration continue : un équilibre délicat entre réflexion et action
L’adoption de cette nouvelle approche a eu un impact sur le temps de cycle de notre équipe, mais les enseignements tirés et les améliorations apportées ont largement compensé ce défi.
Après que la saisie des apprentissages soit devenue partie intégrante de notre flux de travail, nous avons constaté une augmentation du temps de cycle. Il a fallu un certain temps avant que l’équipe ne s’habitue à saisir les apprentissages pour chaque élément (au lieu de commencer quelque chose de nouveau). Nous avons essayé de contrer cela en limitant le travail en cours sur plusieurs colonnes – nous ne commençons de nouveaux éléments que lorsque nous en avons terminé.
Bien qu’il faille encore parfois des “coups de pouce”, les apprentissages qui sont découverts sont inestimables. Le fait que cela se fasse plus près du travail sur l’élément aide beaucoup, car le contexte est plus présent pour tous les participants.
Parmi d’autres choses, nous avons découvert des problèmes dans le code (par exemple, en rendant plus transparent que certaines parties nécessitent une refonte), réfléchi à pourquoi certains éléments étaient plus vieux que la normale (pourquoi cela a-t-il été bloqué et que aurions-nous pu faire à la place ?) et remis en question notre processus actuel (comment se fait-il que nous n’étions pas alignés sur l’objectif de cet élément avant de le commencer ?).
Les leçons tirées de notre transformation : les hauts et les bas de l’amélioration continue au quotidien
Après avoir adopté cette approche d’amélioration continue depuis plus de deux mois, il est temps de faire le bilan de nos succès et de nos défis.
En prenant du recul, nous sommes heureux de réfléchir plus souvent. Il est difficile de dire si toutes ces choses auraient été soulevées lors d’une rétrospective. Je suppose que certaines d’entre elles auraient été oubliées au moment où la rétro aurait eu lieu. Et même si ce n’était pas le cas, nous n’aurions peut-être pas eu le temps d’approfondir tous les éléments.
Nous avons encore du mal à faire en sorte que certains éléments ne soient pas réfléchis. Une hypothèse est que cela pourrait encore être perçu par les développeurs comme s’ils devaient “se justifier”. Parfois, le contenu va dans cette direction. Au lieu de “voici ce que nous pouvons/devrions changer”, c’est plutôt “voici pourquoi cela s’est produit”. Bien que cela puisse être un bon début, cela n’aide pas à s’améliorer. Nous aimerions que chaque développeur participe activement à la définition de notre façon de travailler et espérons obtenir une proposition concrète de ce que nous devrions changer.
Pour améliorer cela, nous aimerions discuter et clarifier l’objectif avec l’équipe. De plus, nous voulons préciser que nous recherchons tout ce qui peut nous aider à améliorer notre efficacité. Ensuite, nous prévoyons d’organiser un atelier pour partager certaines techniques spécifiques pour “extraire” des apprentissages significatifs.
Dans l’ensemble, nous sommes satisfaits de notre approche. Nous pouvons réfléchir sur des éléments spécifiques assez rapidement. Pour les développeurs, c’est agréable car nous n’avons pas à attendre la prochaine rétrospective, mais nous pouvons soulever et potentiellement résoudre les obstacles immédiatement.
La place des rétrospectives dans un monde d’amélioration en flux
Alors, notre approche d’amélioration continue au quotidien a-t-elle rendu les rétrospectives caduques ? Cela signifie-t-il maintenant que la rétrospective est obsolète ? Si nous réfléchissons immédiatement pendant le travail sur des éléments spécifiques, y a-t-il encore besoin d’avoir une rétrospective sur une cadence ?
Pour nous, ces pratiques ne sont pas mutuellement exclusives, mais se complètent bien. Parfois, nous voulons approfondir certains sujets avec toute l’équipe, donc un apprentissage spécifique peut être pris en compte lors de la prochaine rétro pour une discussion ultérieure (s’il est judicieux d’attendre aussi longtemps). De plus, une rétro offre à l’équipe un espace pour explorer d’autres choses qui peuvent ne pas être directement liées à un élément de travail spécifique.
Conclusion
Notre aventure dans l’amélioration continue au quotidien a été passionnante et enrichissante. Nous avons découvert que l’ouverture et le courage sont essentiels pour réussir cette transformation. En adoptant ces principes et en combinant les rétrospectives régulières avec des réflexions pour chaque élément du backlog, notre équipe a atteint de nouveaux sommets d’efficacité et de performance.
L’ouverture sur les choses qui peuvent être améliorées est nécessaire pour apporter plus de transparence à notre façon de travailler. Faire preuve de courage pour aborder ces problèmes est essentiel pour que nous ne nous contentions pas d’inspecter, mais que nous adaptions également notre façon de travailler en continu. Sans ces deux traits vécus dans votre équipe, toute forme d’inspection et d’adaptation sera difficile à réaliser.
Dans Scrum, les rétrospectives ont lieu à la fin de chaque sprint. Bien que cela soit une bonne pratique, il pourrait être judicieux de réfléchir plus fréquemment à notre efficacité. Combiner une rétrospective sur une cadence avec des réflexions pour chaque élément de travail sur lequel nous avons travaillé nous a aidés à nous améliorer en tant qu’équipe.
Cependant, vous devez être conscient que cela pourrait avoir un impact sur votre temps de cycle (si vous en faites partie de votre définition du flux de travail) et que l’équipe doit comprendre l’objectif de cela – il s’agit de trouver de meilleures façons de travailler.
