Le flux de valeur

La rétrospective et l'amélioration continue

La Sprint Retrospective est l'événement où la Scrum Team examine sa propre manière de travailler. Beaucoup d'équipes la tiennent, et peu en tirent des changements durables. Quatre patterns d'A Scrum Book proposent une discipline : choisir une seule amélioration, celle qui mobilise l'équipe, la traiter comme un travail à part entière et se donner le temps d'en mesurer l'effet.

Quatorze idées et aucun changement

L'équipe de français d'un collège compte quatre professeurs. Elle prépare ses séquences et ses évaluations communes par cycles de trois semaines et se réunit une heure à la fin de chaque cycle pour faire le point. Ce jeudi, le tableau se couvre de quatorze idées : harmoniser les barèmes, ranger le dossier partagé, prévenir plus tôt des absences, revoir la progression de grammaire en cinquième. On en retient cinq, que chacun note dans son cahier.

Trois cycles plus tard, les cinq idées figurent toujours sur la liste. « On le dit à chaque fois », remarque l'une des enseignantes. Les idées étaient bonnes. Mais aucune n'avait de responsable, de date ni de place dans l'emploi du temps, et aucune n'était assez précise pour que l'on sache un jour si elle était réalisée.

Sprint Retrospective : s'arrêter pour regarder comment on travaille

Le pattern Sprint Retrospective (rétrospective de Sprint) énonce son problème ainsi : sans attention explicite, les processus et la discipline se dégradent avec le temps. Changer au coup par coup, sans y réfléchir, ajoute au désordre, et ne rien changer fait manquer des occasions de progresser.

Les auteurs expliquent pourquoi les autres événements ne conviennent pas à cet examen. Le Daily Scrum a un horizon trop court. D'un jour à l'autre, les performances varient naturellement, et réagir à ces variations n'a pas de sens. En pleine action, on ne dispose que d'un ou deux points de vue sur un problème. La Sprint Review porte sur le produit et se tient devant les parties prenantes, ce qui n'est pas le cadre pour analyser le fonctionnement interne de l'équipe.

D'autres forces poussent à ne rien examiner du tout. Les Sprints s'enchaînent, et l'on se précipite dans le suivant en répétant les mêmes erreurs. Une équipe qui a déjà progressé se persuade qu'il n'y a plus rien à trouver et que le « vrai travail » presse. Enfin, s'examiner expose à la critique et suscite des comportements défensifs, que les auteurs décrivent d'après Chris Argyris (1991).

La solution est de tenir à la fin de chaque Sprint un événement où la Scrum Team évalue la façon dont elle a travaillé. Le moment est choisi parce qu'un travail achevé donne une vue d'ensemble et que les souvenirs sont encore frais. Les changements proposés peuvent concerner les personnes, leurs relations, le processus, l'environnement ou les outils. Les auteurs rattachent cette pratique au hansei de Toyota, l'examen de conscience qui suit un échec. Elle correspond aussi au dernier principe du Manifeste agile :

« À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. »

Manifeste pour le développement agile de logiciels (2001), douzième principe

Le livre donne plusieurs conseils. Toute la Scrum Team participe, Product Owner compris, pendant trois heures au plus pour un Sprint d'un mois. On ne supprime pas la rétrospective pour finir le travail du Sprint. On s'appuie sur des faits, comme la part du Sprint Backlog terminée et la vélocité, et l'on relève aussi ce qui a bien fonctionné. Pour éviter que la séance ne tourne aux plaintes, les auteurs recommandent la « directive première » formulée par Norman Kerth dans Project Retrospectives (2001) : quoi que l'on découvre, on tient pour acquis que chacun a fait de son mieux compte tenu de ce qu'il savait, de ses compétences, des moyens disponibles et de la situation.

Ils reconnaissent enfin deux limites. Tenir des rétrospectives ne garantit ni l'amélioration ni même la stabilité du processus. Et deux ou trois heures ne suffisent pas pour atteindre les causes profondes, qui tiennent à la structure de l'organisation ou à ses valeurs. Kerth proposait pour cela des rétrospectives de trois jours, hors des locaux.

Scrumming the Scrum : une seule amélioration, inscrite au backlog

Le pattern Scrumming the Scrum (appliquer Scrum à Scrum) part d'une affirmation des auteurs : seule une petite minorité d'équipes Scrum atteint un niveau de performance radicalement supérieur, parce que la plupart ne parviennent pas à repérer et à lever leurs obstacles. Deux forces l'expliquent. Un obstacle difficile demande un effort concentré. Et s'attaquer à plusieurs obstacles en même temps coûte beaucoup de travail pour peu de résultat, ce qui décourage l'équipe.

La solution est de désigner, pendant la rétrospective, l'obstacle le plus important et lui seul, puis de le lever avant la fin du Sprint suivant. Pour cela, on l'inscrit dans le Sprint Backlog comme n'importe quel travail, avec des critères de vérification qui diront quand il est Done, et l'on examine son état à la Sprint Review. Certaines équipes le placent en tête du Product Backlog, pour marquer que l'amélioration est un vrai travail dont le Product Owner a pesé le coût et la valeur. Le Scrum Master tient la liste des obstacles, et toute la Scrum Team est responsable de les éliminer. Le livre attribue l'idée à Hugo Heitz, un spécialiste du Lean, qui la résumait en disant qu'il faut mettre le kaizen dans le backlog. Ce mot japonais désigne l'amélioration continue par petits pas (voir le kaizen dans le corpus Lean).

Happiness Metric : choisir ce qui mobilise l'équipe

Reste à savoir comment choisir. Le pattern Happiness Metric (mesure du bonheur) observe qu'une rétrospective produit beaucoup d'idées et qu'on ignore d'avance lesquelles seront payantes. Les longues listes ont en outre un effet démobilisant, que les auteurs appuient sur les travaux du psychologue Barry Schwartz (2004) concernant l'excès de choix. Il faut donc travailler à la bonne amélioration, et il faut que l'équipe ait envie de la mener.

La solution est de conduire l'amélioration par un seul petit changement à la fois, choisi par consensus. On pose à l'équipe une question qui l'aide à sentir laquelle des options disponibles éveille le plus son engagement, par exemple : qu'avons-nous le plus envie de faire ensemble, au prochain Sprint, pour améliorer notre façon de travailler ? Beaucoup d'équipes utilisent une échelle subjective de 1 à 5. Le livre insiste sur le consensus. Un vote à la majorité ou une décision du Scrum Master sont des formes de contrôle, alors que le ressort du pattern est que l'équipe sente qu'elle décide. L'envie ne dispense pas de réalisme : on précise les critères de vérification et on estime le travail.

Ce pattern est nettement plus long que les autres, parce que ses auteurs y discutent leurs propres doutes. Ils écrivent que le bonheur n'est pas la clé de la mesure du bonheur. D'après les travaux qu'ils passent en revue, le bonheur d'une équipe est lié à ses performances futures, mais les arguments en faveur d'une relation de cause à effet sont rares. Henrik Kniberg, dont la société Crisp a introduit cette mesure dans le monde agile, leur a confié que la moyenne obtenue chez lui restait très stable et n'apprenait presque rien en elle-même. Ce qui agit serait plutôt l'autonomie : une équipe qui choisit ce qu'elle améliore constate qu'elle a prise sur son travail.

Ils rapportent aussi un cas défavorable. Une équipe qui mesurait son bonheur pour lui-même, sans le relier à un but commun, obtint de travailler à domicile, chacun de son côté. Le bonheur déclaré monta durablement, mais la vélocité, après une brève hausse, revint à son niveau antérieur. Les auteurs en concluent que la question posée doit porter à la fois sur l'équipe et sur le produit.

Kaizen Pulse : alterner changement et stabilité

Le pattern Kaizen Pulse (le pouls du kaizen) s'adresse à une équipe dont les résultats sont devenus réguliers et qui veut franchir un palier. Son problème est celui de la mesure. Pour savoir si un changement améliore les choses, il faut une base de comparaison, et l'établir prend plusieurs Sprints. Si la vélocité varie fortement d'un Sprint à l'autre, aucun effet ne se distingue du bruit. Si l'on change plusieurs choses à la fois, on ne sait pas laquelle a agi. Il y a aussi un facteur humain : un groupe a besoin de temps pour assimiler une nouvelle pratique jusqu'à en faire une habitude.

La solution est d'alterner des périodes de vélocité maîtrisée et des impulsions d'amélioration. L'équipe commence par stabiliser sa vélocité, le livre donnant comme repère une variation contenue dans une fourchette de 20 %. Elle introduit ensuite un seul changement et le pratique jusqu'à ce qu'il devienne routinier. Elle revient en arrière si l'expérience montre qu'il nuit. Les auteurs préfèrent parler d'amélioration « continuelle » plutôt que « continue », et attribuent ce schéma à un ouvrage de Hirotaka Takeuchi et de ses collègues sur Toyota (2008).

Ils ajoutent un avertissement. La vélocité sert à prévoir, elle ne mesure pas la valeur. Un changement peut l'augmenter tout en dégradant ce que le produit apporte, et l'on ne s'en apercevra pas si l'on ne regarde qu'elle. Il faut donc suivre aussi d'autres indicateurs, comme les défauts ou la valeur livrée.

Ce que dit le Guide Scrum 2020

• Le Guide donne pour but à la Sprint Retrospective de planifier des moyens d'améliorer la qualité et l'efficacité. La Scrum Team y inspecte le dernier Sprint sous l'angle des individus, des interactions, des processus, des outils et de sa Definition of Done.
• La durée maximale est de trois heures pour un Sprint d'un mois, comme dans le livre. La rétrospective conclut le Sprint.
• L'édition 2017 exigeait que le Sprint Backlog contienne au moins une amélioration de processus prioritaire issue de la rétrospective précédente, ce qui revenait à rendre obligatoire le pattern Scrumming the Scrum. L'édition 2020 est plus souple : les améliorations les plus utiles sont traitées dès que possible et peuvent être ajoutées au Sprint Backlog suivant.
• Le Guide fait participer toute la Scrum Team. Le livre envisage, à titre exceptionnel, que les développeurs demandent au Product Owner de ne pas assister à une séance, et y voit le signe d'un problème plus grave.
• La mesure du bonheur, la vélocité et la liste des obstacles n'apparaissent pas dans le Guide.

Limites et pièges

Une rétrospective sans suite produit l'effet inverse de celui recherché, car elle apprend à l'équipe que parler ne change rien. Le pattern Scrumming the Scrum vise ce défaut, à condition que le temps de l'amélioration soit réellement pris sur le Sprint.

Beaucoup d'obstacles ne dépendent pas de l'équipe. Un outil imposé, une règle d'achat ou une équipe sans cesse recomposée ne se corrigent pas entre collègues. Le livre prévoit alors de solliciter les managers, comme l'explique l'article sur la protection du Sprint.

La séance peut aussi être détournée. Quand un responsable y vient pour dire à l'équipe comment s'améliorer, elle devient un instrument de pression, ce que Ron Jeffries a décrit sous le nom de « Dark Scrum » (2016). La directive de Kerth suppose une confiance qui ne se décrète pas.

Il faut enfin lire avec prudence les chiffres du livre. Le pattern Scrumming the Scrum affirme que lever l'obstacle principal doit produire une amélioration immédiate et que, dans le cas contraire, l'équipe a mal analysé la situation. Un raisonnement construit ainsi ne peut jamais être pris en défaut. L'exemple de vélocité doublée que donne le pattern est tiré d'un entretien accordé par Jeff Sutherland, et le cas de l'entreprise danoise Systematic, qu'il cite aussi, d'une communication de 2009 dont Sutherland est coauteur. Aucun des deux ne vient d'observateurs indépendants. L'exemple chiffré donné plus haut est fragile pour une autre raison : onze Sprints de deux semaines représentent plus de cinq mois, pendant lesquels bien d'autres choses ont pu changer. L'article critique du corpus revient sur la valeur de ces affirmations.