La rétrospective, ADN de l'Agilité

La fin de l'année approche 🎊, un cycle s'achève, l'occasion de faire une rétrospective de votre année si ce n'est déjà fait, et l'occasion pour moi d'évoquer l'importance de cette pratique agile.

Réinterroger vos pratiques agiles

On reproche bien des choses au cadre Scrum. Certains de ces reproches sont fondés, à condition toutefois de savoir précisément de quoi on parle et de ne pas simplement crier avec les loups. Libre à chaque équipe de prendre la distance qu'elle veut par rapport au cadre de travail, peu importe que la pratique ainsi trouvée s'y inscrive encore ou non : pourvu que ça marche !

Vous pourriez ainsi travailler sans faire d'estimations (No-Estimate), vous pourriez même travailler sans faire de sprints. L'important étant, si vous faites des sprints ou des estimations, de le faire à raison et non pas "parce qu'on a toujours fait comme ça". Et de réinterroger votre pratique périodiquement. Dans la même lignée, vous pourriez faire des Daily Meetings comme vous pourriez ne pas en faire : il existe plusieurs façons de vous synchroniser et de piloter le sprint collectivement. N'obéissez pas, réfléchissez !

La rétrospective, lieu de l'amélioration continue

En revanche, s'il est une chose à laquelle vous ne devez pas renoncer, c'est bien la rétrospective, parce que la rétrospective est le lieu de l'amélioration continue. Vous connaissez comme moi la puissance des intérêts composés : si votre efficacité collective ne gagne ne serait-ce qu'1% à chaque sprint (disons toutes les 2 semaines), c'est 30% d'efficacité gagnée à la fin de l'année.

Comment l'animer ? Là encore, sentez-vous libres de faire ce que bon vous semble, pourvu que ça marche : Keep/Drop/Start, Sailboat ou SWOT, toutes ces approches disent peu ou prou la même chose et ne sont qu'un support à la discussion. N'hésitez pas à varier, d'ailleurs, cela vous évitera de tomber dans la routine. En revanche, j'ai observé plus d'une fois des équipes qui, à trop vouloir observer le formalisme de la rétrospective, en perdaient l'esprit. Mieux vaut à mon sens mettre les pieds dans le plat s'il y a un gros sujet qui tâche, quitte à faire voler le formalisme en éclats.

Derrière l'amélioration continue, la résolution de problèmes

Plus profondément, l'amélioration continue est un état d'esprit, c'est la détermination à rechercher le positif en toute chose. Cela commence par la célébration des succès, même minimes. Ensuite, il y a ce qui n'a pas marché ou ne marche pas. Et là, bien plus que le formalisme précédemment évoqué, la capacité à revenir aux causes premières des problèmes me paraît essentielle : ne vous limitez pas à l'explication de surface, posez-vous autant de fois qu'il le faut la question du "pourquoi ?" (méthode des 5 whys). Tant que la cause première n'est pas éteinte, le problème reviendra.

Exemple : "on n'a pas le temps de recetter les développements durant le sprint".

• Pourquoi ? Parce que la recette de chaque ticket prend plusieurs jours ;
• Pourquoi ? Parce que tous les tickets arrivent tous en même temps en recette, en fin de sprint ;
• Pourquoi ? Parce que les tickets sont trop gros, on devrait les découper mais on n'y arrive pas ;
• Pourquoi ? Parce qu'on ne découpe pas en fonction de la valeur apportée à l'utilisateur ("tickets" ➡️ "User Stories") ;
• Pourquoi ? Parce qu'on ne sait pas ce qui est acceptable ou non pour les utilisateurs ;
• Pourquoi ? Parce qu'on n'interagit pas assez avec les utilisateurs ;

Et ainsi de suite.

Pour toutes ces raisons, la rétrospective est bien l'ADN de l'Agilité : elle est le support dont tout se déduit.

Sur ce, joyeux Noël 🎄 et prenez soin de votre estomac 😉