Rétrospectives Agile, Pouvez-vous les omettre ?
Les équipes parfois considèrent d'omettre une rétrospective. Par exemple lorsqu'elles sont sous pression par le temps, ou qu'elles ne voient pas de bénéfices directs à en faire une. Ensuite elles se demandent si elles devraient maintenir les rétrospectives ? Les rétrospectives agiles aident les équipes à apprendre et à s'améliorer continuellement, et il y a des raisons valides pour les maintenir, même avec une équipe mûre.
Dave Moran mentionne que dernièrement il entend de plus en plus demander si nous pouvons sauter la rétrospective ?. Lorsqu'on lui pose la question, il suggère :
Demander à une équipe ce que signifie pour eux être agile et les rediriger vers le Manifeste Agile est utile dans ces situations. L'un des principe indique : "À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence."
D'après son expérience la façon dont l'amélioration est conduite change lorsque les organisations adoptent l'agilité :
La rétrospective est une opportunité pour l'équipe de s'arrêter, de réfléchir et d'apprendre. C'est un mécanisme clé implémenté dans Scrum afin de soutenir l'amélioration continue, un concept difficile à mettre en place pour un grand nombre d'entreprises non-agile. L'amélioration dans des environnements non-agile vient par à-coups, apparaissant généralement comme des pratiques unilatéralement imposées et ajoutées à un processus de développement déjà surchargé visant à couvrir n'importe quels scénarios.
Dave explique pourquoi il est important d'expliquer comment l'agilité soutient l'amélioration continue, et comme utiliser des pratiques agiles, telles que les rétrospectives, impacte les approches utilisées par les organisations pour gérer le changement :
Nous cherchons à exclure toute la surcharge non-essentielle pour garder une approche du travail simple et directe qui implique combiner des tâches traditionnelles et des fonctions pour accélérer la livraison - avec de la qualité. Si nous voulons éliminer cette surcharge que la plupart des organisations pensent être nécessaire (aujourd'hui), nous devons avoir quelque chose pour relativiser leurs inquiétudes. L'amélioration continue via les rétrospectives assure que les équipes agiles sont intéressées par leur productivité et leur efficacité. Les rétrospectives réduisent les inquiétudes vis-à-vis de l'agilité et permettent aux implémentations agiles d'augmenter l'efficacité par rapport à des approches existantes - ce qui est ce que nous devons démontrer.
Dans ne jamais sous-estimer l'importance de l'amélioration continue, James Harvey explique comment les équipes qui ne font plus de rétrospectives risquent de devenir moins productives :
D'après mon expérience avec des équipes agiles, les réunions de rétrospective de sprint sont omises lorsqu'un certain niveau d'efficacité est atteint parce "Hey, on fait déjà du bon travail, alors pourquoi devrions-nous chercher des choses qui ne vont pas ?" C'est ici que le danger d'entrer en zone de confort devient une réalité. Sans rien faire de mal, vous verrez que l'équipe perd de la vélocité, de l'efficacité et de la motivation avant d'entrer dans un état d'esprit avec l'idée que le travail sera fait sans aucun effort.
Son opinion est qu'il y a quelque chose à gagner pour les équipes à continuer de faire des rétrospectives :
La difficulté de l'amélioration devient plus grande, mais la récompense est aussi énormément augmentée.
Brian Copeland a écrit un billet de blog Agile vs Fragile : La rétrospective va de l'avant, où il décrit comment les équipes "fragiles", "les équipes qui utilisent l'agilité comme une excuse pour de mauvaises pratiques de livraison de projet" voient les rétrospectives :
C'est l'un des domaines où beaucoup d'équipes ont laissé tomber. Ils ne prennent pas le temps de faire des rétrospectives parce que les gens ne comprennent pas la valeur qu'elles ajoutent. Elles sont perçues comme une perte de temps qui pourrait être dépensé sur le prochain sprint. Les équipes fragiles font peut-être des sessions de leçons apprises, mais seulement parce que le guide agile leurs dit qu'ils doivent le faire. Elles ne sont pas prises au sérieux, et on donne rarement suite aux résultats. Elles deviennent des sessions de "jeu du blâme" où chacun essaie de s'assurer que l'échec du sprint n'était pas de leur responsabilité, et que le sprint aurait été réussi si seulement l'autre équipe avait fait quelque chose différemment.
Le problème avec les rétrospectives par des équipes fragiles vient de la façon dont ces équipes adoptent l'agilité :
Ce que ces équipes n'arrivent pas à comprendre est que le problème ne vient pas de la méthodologie qu'ils choisissent, mais de la discipline qu'ils ont à exploiter cette méthodologie qui détermine leur succès. Quand les équipes adoptent une méthodologie, mais n'embrassent pas totalement les principes, cela mène à des résultats imprévisibles et inconsistants. Cela devient vraiment fragile.
Justin Carmony écrit dans son blog sur les résultats que son équipe a obtenu en faisant des rétrospectives dans le catalyseur pour le développement agile : la rétrospective de sprint. Il commence par expliquer la situation dans laquelle ils se trouvaient avant de faire des rétrospectives :
(…) lorsque j'ai rejoint et que j'ai commencé à gérer l'équipe Deseret News, nous avions notre propre processus agile : sprints, estimations, standups, planification, etc. Cela fonctionnait bien pour la plupart, mais nous avions tout de même du mal en tant qu'équipe à trouver notre prochain niveau de productivité. On a toujours eu l'impression qu'il nous manquait quelque chose, alors on a expérimenté. D'un sprint d'une semaine à deux semaines, le jour où se réunir, qui était impliqué dans quoi, etc... Mais peu importe ce que nous faisions, nous avions le sentiment de juste changer l'ordre des choses. Nous ne pouvions pas atteindre ce prochain niveau de productivité.
Ils ont introduit les rétrospectives de sprint dans leurs sessions de planification :
On a continué toutes les deux semaines dans notre réunion de sprint planning de revenir sur notre sprint précédent lors de notre rétrospective. (....) Juste une liste de choses qui se sont bien passé et d'autres non, et ce que nous voulions changer. Nous regardions la liste du sprint précédent et regardions comment nous avions fait les choses qu'on avait décidé de changer pour s'assurer que nous les avions faites. Semaine après semaine, nous prenions ce temps pour revoir le processus et voir ce que nous voulions changer.
Après avoir fait 10 rétrospectives, ils ont vu le résultat qu'avaient les rétrospectives sur leur productivité, leur façon de travailler et sur les dates de livraison :
Nous avons doublé notre vélocité en tant qu'équipe. Quand nous avons commencé ce processus, nous nous attaquions à de gros problèmes tels qu'un backlog et des tâches qui manquaient de définition. Une fois que ces derniers étaient réglés, nous avons commencé à remarquer d'autres choses qui aideraient à mettre le processus en place. De toute façon, ces choses à changer n'auraient jamais été remarquées si nous n'avions pas itéré régulièrement sur notre processus. Ce n'est pas juste notre vélocité qui a augmenté : nous atteignions nos dates de livraison bien mieux. Nous sommes capables de prendre des décisions à propos de fonctionnalités avec beaucoup plus de confiance. Quand une nouvelle fonctionnalité est demandée, nous pouvons estimer son impact sur notre date de livraison et décider quoi faire.
Son conseil : "Si vous ne faites pas de rétrospectives, commencez. Si vous en faites, partagez-le avec d'autres" :
Je crois profondément que la rétrospective débloque le potentiel du développement agile : nous sommes passé de l'expérimentation autour de notre processus à itérer dessus. Ce qui me tue est qu'à chaque fois que j'ai entendu quelqu'un parler du processus agile, je n'ai jamais rien entendu à propos de faire une "rétrospective". J'ai entendu parler d'estimation, de backlogs, de sprints, de vélocité, mais le concept central, le véritable catalyseur qui peut faire passer l'intégralité du processus agile au niveau suivant, n'a jamais attiré mon attention.