Chapitre 6

Tirer le meilleur des sprints

Dans ce chapitre :

Tirer parti du Scrum quotidien
Essaimer pour « terminer »
Conduire des revues de sprint efficaces
Trouver les éléments clés dans une rétrospective de sprint

Le sprint étant l’essence de Scrum, c’est le minimum que de lui consacrer un chapitre entier. Vous avez déjà pu vous en faire une idée – une période calibrée pour que l’équipe de développement puisse trouver un rythme de développement. C’est aussi ce qui favorise l’évaluation et l’adaptation.

Mais ce n’est pas tout. Dans ce chapitre, vous découvrirez le Scrum quotidien, 15 minutes irremplaçables, qui vous permettront chaque jour de vous focaliser sur vos objectifs à court terme et de vous organiser pour les atteindre comme jamais auparavant. Facilité par un Scrum Master, votre projet restera sur les rails, tandis que l’équipe Scrum traitera les obstacles et coordonnera les priorités du jour.

Vous découvrirez aussi la revue et la rétrospective de sprint. Lors de ces deux réunions, vous porterez le concept d’évaluation et d’adaptation à un nouveau niveau. Les parties prenantes procéderont à la revue du produit développé et fourniront au propriétaire du produit un retour immédiat, et l’équipe Scrum pourra elle-même évaluer ce que le sprint a donné en réalité et intégrer les améliorations nécessaires à son processus.

Le Scrum quotidien – Étape 5

Le Scrum quotidien est un des cinq évènements Scrum, et l’étape 5 sur la feuille de route de création de valeur. Reportez-vous à la Figure 6-1. Comme vous l’aurez noté, la planification joue un rôle énorme dans Scrum. Vous ne vous contentez pas de fixer un objectif, de l’oublier, puis de vous réunir six mois plus tard pour voir ce que ça a donné. Vous évaluez et adaptez au quotidien.

Figure 6-1 : Le Scrum quotidien est un moment essentiel du sprint et l’étape 5 de la feuille de route de création de valeur.

Étape 5 : Scrum Comme l’équipe de développement se concentre comme un essaim chaque jour pour réaliser une exigence, la coordination est essentielle. Il est aussi crucial de lever tous les obstacles pour permettre aux développeurs de collaborer étroitement afin de livrer des évolutions sous la forme de produits potentiellement livrables au terme de brèves itérations. Le Scrum quotidien est ce qui vous permet d’y parvenir.

Si vous gérez vos projets à la semaine (c’est-à-dire, si vous faites des rapports hebdomadaires, jusqu’à une semaine après, et qui ne sont pas forcément revus le jour même où vous les produisez), vous prenez le risque de déraper d’une semaine. Dans Scrum, vous pouvez toujours déraper, mais seulement d’un jour, car l’équipe Scrum gère au jour le jour, en s’appuyant sur le backlog du sprint, le Scrum quotidien et une interaction directe et quotidienne.

Qu’est-ce que le Scrum quotidien ?

Comme son nom l’indique, c’est un évènement quotidien qui se déroule durant un sprint. La timebox est de 15 minutes maximum, quelle que soit la durée du sprint. Les réunions dans Scrum, comme les artéfacts, sont limités au strict nécessaire. Tout ce qui dépasse 15 minutes consommerait un temps précieux de développement. De plus, c’est largement suffisant.

L’objectif du Scrum quotidien est de coordonner les activités du sprint et d’identifier les obstacles qui pourraient empêcher l’équipe de développement d’atteindre l’objectif du sprint. Tous les membres de l’équipe de développement participent, si bien que chacun sait sur quoi l’autre travaille. Si un obstacle surgit lors d’un Scrum quotidien, il est géré durant le sprint, le jour même. C’est une réunion de coordination, pas un recueil des plaintes ni une séance de résolution de problème.

Le Scrum Master en personne supprime les obstacles, ou facilite leur suppression. Quelques obstacles peuvent nécessiter l’intervention du propriétaire du produit, voire une discussion entre un membre de l’équipe de développement et quelqu’un d’extérieur.

Le Scrum quotidien est l’occasion d’évaluer et d’adapter dans l’heure !

Comme le Scrum quotidien ne dure que 15 minutes, tout le monde a besoin d’être prêt à l’heure. Vous pourrez observer une corrélation directe entre le retard d’un Scrum et le déficit d’attention lorsqu’il démarre enfin. L’équipe peut parvenir à être ponctuelle de plusieurs manières, comme par exemple :

Commencer le Scrum quotidien une demi-heure après l’heure à laquelle débute la journée de travail habituelle.
Cela donne à l’équipe de développement le temps de prendre un café, de répondre aux courriels, de discuter des facéties de la veille, et de se livrer à son rituel matinal.
Pénaliser les membres qui sont en retard d’une manière amicale et inspirée.
Faites-les contribuer à un fonds de célébration pour chaque minute de retard. Ou demandez-leur de pousser la chansonnette. Soyez créatif et rendez le moment assez désagréable pour mettre un terme à ces retards.
Une équipe Scrum de Portland a mis en place l’incitation « multiplicateur de 20 euros ou de 20 pompes ». La première fois qu’un membre est en retard, il doit payer 20 euros ou faire 20 pompes. La fois suivante, c’est 40 euros ou 40 pompes, et ainsi de suite. C’est l’équipe qui a trouvé cela ; on ne lui a pas imposé. Cela a bien fonctionné en prévenant radicalement les retards.

Les participants au Scrum quotidien sont les membres de l’équipe de développement et le Scrum Master. Le Scrum Master veille à ce que le Scrum quotidien se déroule et que l’équipe de développement le dirige. Le propriétaire du produit peut y assister, mais uniquement si l’équipe de développement le requiert. Le propriétaire du produit peut fournir des clarifications et préciser des priorités, et toute autre personne impliquée peut venir écouter. Toutefois, ni le Scrum Master ni le propriétaire du produit ne peuvent s’exprimer. De la sorte, ils peuvent bénéficier de la transparence du processus quotidien, mais ils ne peuvent pas le gêner, et encore moins le faire dérailler.

Une mauvaise idée reçue sur le Scrum quotidien, c’est que c’est un moment lors duquel l’équipe de développement fait son rapport au propriétaire du produit, ou un moment lors duquel le propriétaire du produit peut présenter de nouvelles exigences. Cela remet en question le principe des brèves itérations qui permet aux développeurs de rester focalisés sur un ensemble de tâches et les conduire à bien en vue d’atteindre un objectif métier bien défini. Le Scrum quotidien n’est pas une réunion pour faire un point d’avancement. C’est une réunion de coordination pour maximiser la performance.

Aussitôt que le Scrum quotidien commence à ressembler à un point de reporting, ou que les membres de l’équipe de développement commencent à faire leur « rapport » à quelqu’un (par exemple, un « leader » informel ou le Scrum Master), c’est qu’il a déraillé. Le Scrum quotidien se déroule entre pairs. Ce n’est pas le moment où chacun doit présenter son rapport à quelqu’un, comme le Scrum Master ou le propriétaire du produit. Il doit rester centré sur le besoin d’une équipe auto-organisée de se coordonner, en identifiant les obstacles et s’assurant qu’ils seront levés aussitôt que possible.

Souvent durant le Scrum quotidien, je regarde mes chaussures, voire je me promène à l’écart. De cette manière, si les gens me font un rapport ou essaient d’attirer mon attention, je peux leur répondre « Pourquoi s’adresser à moi ? Cette réunion, c’est pour vous les gars ». Cela fonctionne bien pour rappeler dans quel but se tient la réunion.

Que fait-on durant un Scrum quotidien ?

L’équipe de développement se réunit, et chaque membre fait trois déclarations. Chacune de ces déclarations est formulée dans le souci d’aider l’équipe à atteindre l’objectif du sprint :

Hier, j’ai réalisé cela…
Aujourd’hui, je vais me concentrer sur…
Les obstacles que je rencontre sont…

Le Scrum quotidien est tout entier consacré à la manière dont l’équipe de développement s’auto-organise. Chaque jour, ses membres décident de qui va faire quoi et de qui aidera qui. Ça ne leur est pas dicté par un chef de projet ou tout autre membre extérieur.

Imaginons une équipe Scrum qui se rassemble pour se pencher sur le backlog du sprint ou le tableau des tâches au début de la journée. Chacun peut constater en un coup d’œil les progrès accomplis la veille, puis chacun choisit de manière proactive une nouvelle tâche à accomplir le jour même. Les membres de l’équipe se coordonnent pour apporter de l’aide là où elle est requise afin d’accomplir la tâche avant la fin de la journée, puis se plonge dans son travail.

Comme je l’ai expliqué au Chapitre 5, les tâches doivent être décomposées pour être accomplies en un jour ou moins. Mais même alors, quand les développeurs sont livrés à eux-mêmes durant quelques jours ou qu’ils ne parviennent pas à se coordonner, ils peuvent facilement rester bloqués sur des détails ou des problèmes insignifiants qui pourraient facilement être réglés par deux paires d’yeux au lieu d’une. Les Scrums quotidiens permettent de synchroniser l’équipe, pour que chacun travaille en ayant à l’esprit l’aide qu’il doit apporter aux autres pour que le travail soit réalisé. Le lendemain, les membres de l’équipe échangent avec excitation sur les progrès accomplis plutôt que sur un sinistre bilan, du style « Je suis toujours sur le truc dont j’ai parlé hier et avant-hier ».

Un jouet pour chien qui siffle dans Scrum ? C’est ce que je lançais à un membre de l’équipe de développement pris au hasard pour lui donner la parole, car je ne voulais jamais fixer d’ordre de prise de parole. Fixer un tel ordre encourage les gens à partir dès que leur tour est passé, ou pire, à arriver en retard, juste avant le tour. Aussi, si quelqu’un parle trop longtemps, j’utilise un minuteur de cuisine ou une rame de papier – cela pèse 2 kg – et je le laisse parler tant qu’il peut la tenir à bout de bras. Le Scrum quotidien reste ainsi rapide, utile pour progresser, et amusant.

Durant le Scrum quotidien, j’aime que le Scrum Master participe, au-delà de la facilitation, en évoquant les obstacles détectés et/ou en train d’être levés. Par exemple, une fois que les membres de l’équipe ont parlé, le Scrum Master rajoute :

Hier, j’ai levé cet obstacle…
Aujourd’hui, je peux lever cet obstacle…
Les obstacles que je ne peux lever sont… et je vais rencontrer un tel et tel autre qui peuvent m’aider.

Des études ont montré que les réunions qu’on tient debout durent 34 % moins de temps que celles qu’on tient assis.

Les tactiques suivantes peuvent préserver la rapidité et l’efficacité de votre Scrum quotidien :

Démarrer toujours à l’heure.
Conduire la réunion debout.
Ainsi, personne n’a la possibilité de s’affaler dans sa chaise et de se relaxer. À l’inverse, tout le monde a plutôt le sentiment d’être déjà sur le départ.
Focaliser la réunion sur la coordination, et non sur la résolution de problèmes.
Les obstacles ne sont levés qu’après le Scrum quotidien.
Le Scrum Master est le facilitateur de la réunion, il peut veiller à ce qu’elle ne déborde pas sur le temps et sur les sujets si nécessaire, et aussi veiller à ce que les membres de l’équipe de développement participent. La « touche » apportée par le Scrum Master devrait être aussi légère que possible.
Le titre d’un documentaire sur la vie quotidienne du Scrum Master pourrait être Retire-toi et bosse.
Ne traitez que les sujets et les priorités qui sont en relation directe avec l’objectif du sprint du jour.
Réunissez-vous autour d’une représentation du backlog du sprint de l’équipe (le tableau des tâches, abordé dans la section suivante) pour ne pas perdre de vue le contexte et rester concentré.
Ne permettez pas des déclarations vagues et ne vous en remettez pas à la mémoire des membres de l’équipe pour savoir ce qui figure dans le backlog du sprint.

Lorsque des obstacles sont découverts lors du Scrum quotidien, ils peuvent être traités par le Scrum Master qui procède à un after. C’est une réunion qui se tient immédiatement après le Scrum quotidien, à laquelle ne participent que ceux qui sont concernés, et qui a pour objet de traiter les problèmes qui sont ressortis lors du Scrum quotidien, comme un développeur demandant à un autre développeur comment résoudre un problème particulier rencontré sur une tâche, ou trouver un moyen de résoudre un conflit entre deux tâches.

Le tableau des tâches de l’équipe

Un tableau des tâches est une manière d’afficher le backlog du sprint. Même s’il est fréquent qu’une équipe Scrum gère le backlog du sprint par informatique, vous n’avez en fait besoin que d’un tableau des tâches sur un mur, de quelques Post-it et de ruban adhésif ! La Figure 6-2 vous montre un exemple de tableau des tâches.

Figure 6-2 : Un tableau des tâches.

Un tableau physique est une excellente chose, car il est possible de visualiser l’état d’avancement de l’équipe rapidement et facilement, d’un coup d’œil. Disposer des tableaux de ce type dans le champ de vision de l’équipe de développement et du propriétaire du produit permet de s’assurer qu’ils visualisent instantanément ce qui est fait, ce qui n’est pas fait, et tout ce qui est en cours. Utilisez ces éléments de base pour construire votre tableau :

L’en-tête :
- • L’objectif spécifique du sprint
- • L’objectif général de la livraison
Il est possible d’indiquer aussi les dates de livraison et de fin du sprint.
Les colonnes (de gauche à droite) :
- • À FAIRE : Les exigences et les tâches qui doivent être développées lors du sprint.
- • Les développeurs partent du haut de cette liste pour démarrer une nouvelle tâche. Si plusieurs développeurs souhaitent la même tâche, ils peuvent s’apparier pour travailler dessus, l’un peut rester dans l’ombre de l’autre (shadowing), ou alors ils peuvent décider qui est le plus à même de traiter la tâche.
- • EN COURS : Les éléments du backlog du produit sur lesquels l’équipe de développement travaille.
- • Chaque tâche peut comporter des points ou des Post-it colorés pour désigner les propriétaires, ou pour identifier les tâches bloquées par un obstacle. Si elles sont utilisées, les limites du travail en cours (WIP, pour work in progress) doivent être affichées dans cette colonne. Une fois que des développeurs ont terminé une tâche, ils regardent d’abord ici pour voir qui ils pourraient aider à terminer. Sinon, ils prennent une nouvelle tâche dans À FAIRE et contrôlent avec l’équipe si c’est la bonne tâche à développer ensuite.
- • À ACCEPTER : Les exigences qui attendent d’être acceptées par le propriétaire du produit.
- • Si l’exigence est rejetée, et qu’il reste assez de temps durant le sprint, elle revient dans EN COURS. Autrement, l’exigence revient dans le backlog du produit pour être prise en compte lors d’un futur sprint (voir le chapitre suivant).
- • TERMINÉ : Les exigences que le propriétaire du produit a acceptées, qui sont donc considérées comme terminées.

Si l’équipe de développement peut déplacer les exigences de À FAIRE à EN COURS puis dans À ACCEPTER, seul le propriétaire du produit peut en déplacer de À ACCEPTER à TERMINÉ. Si une exigence est rejetée, l’équipe de développement replace les tâches dans EN COURS pour les retravailler, ou crée de nouvelles tâches pour traiter la raison pour laquelle l’exigence a été rejetée.

La matérialité du tableau des tâches, tout comme celle de la feuille de route du produit, renforcent l’engagement de l’équipe et sa flexibilité. C’est concret. C’est tangible.

Les exigences de la colonne À ACCEPTER ne devraient pas s’accumuler. Dans l’idéal, il ne faudrait pas qu’il s’écoule plus d’un jour entre le moment où une carte est placée dans la colonne À ACCEPTER et celui où elle est placée dans la colonne TERMINÉ ou REJETÉE pour être reprise lors d’un développement ultérieur. Si ce délai est dépassé, le propriétaire du produit a besoin d’être coaché pour ne pas laisser les histoires utilisateur s’accumuler dans l’attente d’être acceptées. Si le propriétaire du produit est un membre dédié de l’équipe Scrum, disponible à tout instant pour apporter des clarifications à l’équipe de développement, si les exigences ont été décomposées autant que possible, et qu’elles peuvent être considérées comme terminées, il n’y a pas de raison qu’il faille attendre. Il est essentiel que l’équipe de développement sache que son travail est terminé afin de pouvoir enchaîner avec la suite.

Le tableau Kanban

Kanban est un terme japonais pour « pancarte », « tableau de signalisation » ou « carte que vous pouvez voir ». Dans les années 50, Toyota a formalisé ce concept pour standardiser le flux des pièces détachées sur les lignes de production. En gros, un tableau Kanban contient des cartes, qui chacune représente un travail à faire. Chaque carte est comme un signal qui indique quand un nouveau travail peut être entrepris.

Cette pratique a inspiré la pensée lean et des pratiques de fabrication manufacturières. Nombre d’équipes agiles utilisent le système Kanban. Le tableau des tâches fonctionne de façon assez similaire, en ceci qu’il donne à voir (signal) où chaque tâche en est exactement (travail) dans le processus global. Ce niveau de visibilité permet à l’équipe de développement de se discipliner plus facilement pour tenir ses limites de travail en cours (WIP) et de s’épauler.

Essaimer

Au Chapitre 5, j’ai présenté le concept d’essaimage dans le contexte du backlog d’un sprint. L’essaimage survient quand tous les membres de l’équipe de développement se mettent à travailler sur la même exigence pendant le sprint. Quoique ce ne soit pas un principe spécifique à Scrum, c’est un moyen tellement efficace pour permettre à l’équipe de réaliser ce qui figure dans le backlog du sprint, qu’il faut en parler un peu.

Encore une fois, l’un des principaux bénéfices de Scrum, c’est que l’équipe de développement réalise les exigences pour répondre à la définition de « terminé » correspondant à une amélioration du produit qui pourrait être livré dans une timebox donnée, répétant le cycle encore et encore en se basant sur les leçons tirées des retours. L’objectif est de terminer, et pas seulement de démarrer, autant d’exigences que possible.

L’essaimage procure les bénéfices suivants à l’équipe :

De plus grandes chances de réussir en combinant les compétences de tous les membres de l’équipe.
Terminer le cycle complet de la planification, du design, du développement et du test pour chaque exigence.
Résoudre les problèmes et lever les obstacles aujourd’hui, sur l’instant.
Réduire spectaculairement l’apparition de défauts dans le produit grâce au travail en binôme et au monotâche (par opposition au multitâche).
Combler des faiblesses dans la connaissance, le processus, les compétences.
Les exigences les plus importantes sont réalisées, entièrement, en premier lieu.

Lorsque les membres de l’équipe voient tous leurs collègues travailler sur une seule tâche, et qu’il ne leur reste rien sur quoi travailler pour la même exigence (l’histoire utilisateur), il est parfaitement naturel qu’ils jugent plus productif de se lancer sur une nouvelle exigence plutôt que d’aller aider les autres sur celle en cours. Toutefois, cette tendance peut dégénérer jusqu’au point où l’équipe a plusieurs exigences en cours, mais qu’aucune n’est terminée. En pratiquant le shadowing, le travail en binôme, l’assistance sous toutes les formes requises pour terminer la tâche, l’équipe de développement contournera ce risque.

Restez concentrés. Cessez de démarrer et commencez à terminer.

Ce processus vous permet de vous assurer qu’à chaque sprint, quelque chose sera complètement développé et pourra être montré aux parties prenantes. Chaque sprint permettra de produire des résultats « livrables ». Les efforts de l’équipe de développement sont concentrés, le travail d’équipe est développé pour que chacun soit incité à aider les autres, et le processus itératif de Scrum est mis en branle.

Récemment, Microsoft a conduit une étude sur les effets du multitâche. Les résultats sont que le multitâche, ça ne marche tout simplement pas. En moyenne, il faut 15 minutes à votre cerveau pour revenir au niveau où il se trouvait quand vous avez répondu au téléphone ou à un courriel. Les études ont aussi montré qu’une interruption aussi brève que 4,4 secondes triple le nombre d’erreurs réalisées sur tâches qu’il faut exécuter en séquence. En réduisant le multitâche dans votre équipe de développement, vous partirez du bon pied pour gagner les 30 et 40 % de temps de mise sur le marché que j’ai si souvent constatés.

On désigne par trashing (littéralement : jeter à la poubelle), la situation où les développeurs vont et viennent entre les projets, les exigences et les tâches – basculer d’un contexte à un autre. Avec le trashing, il faut 30 % de temps en plus pour terminer les tâches. Si vous n’avez pas assez de bras pour affronter en essaim la charge de travail, c’est que vous n’avez certainement pas de temps à perdre avec du trashing.

Si une exigence placée dans la colonne À ACCEPTER est rejetée par le propriétaire du produit, les développeurs ont plusieurs options :

Terminer leurs tâches courantes, et lorsqu’ils les ont achevées, essaimer sur l’exigence rejetée.
Ce peut être la meilleure option s’il reste beaucoup de temps dans le sprint pour terminer les tâches courantes et l’exigence rejetée.
Abandonner leurs tâches courantes et essaimer sur l’exigence rejetée.
Ce peut être la meilleure option s’il ne reste pas trop de temps dans le sprint pour terminer les deux.

Les exigences inachevées

Même une équipe de développement hautement performante qui estime bien, qui essaime et qui respecte sa limite de travail en cours (WIP) peut terminer un sprint alors qu’il reste des exigences inachevées, voire pas démarrées, dans le backlog du sprint.

Ce n’est pas forcément problématique, tant que l’équipe a essaimé sur les priorités et les a terminées, et qu’elle a produit une amélioration du produit qui peut être livré.

Mais que faire de ces exigences qui restent ? Travailler le week-end pour les terminer ? Travailler « en coulisses » ? Montrer qu’elles sont en cours de réalisation aux parties prenantes lors de la revue du sprint, alors qu’elles ne sont pas terminées ?

Selon ce qui a été terminé durant le sprint, une exigence inachevée ou même pas démarrée peut ne plus s’avérer nécessaire, ou du moins peut ne plus représenter autant de valeur qu’auparavant. Ce qui a été réalisé peut suffire, et il peut être temps de passer à une fonctionnalité différente.

Quel que soit l’effort qui a été déployé, comme l’exigence n’est pas terminée, elle ne peut pas être comptabilisée dans le calcul de la vélocité de l’équipe pour ce sprint. Si l’exigence est affectée à un sprint ultérieur, elle devra être raffinée, clarifiée et estimée de nouveau en fonction du travail qu’il reste à fournir. Vous ne pouvez pas accumuler les points d’histoire.

Une exception toutefois : lorsque vous avez travaillé sur une exigence inachevée, vous pouvez la découper pour terminer une exigence durant le sprint et envoyer l’autre dans le backlog du produit pour être estimée et priorisée.

Dans tous les cas, toute exigence, à tout instant, doit mériter l’investissement que vous y consacrez.

La leçon de tout ça ? Essaimez et terminez.

Le propriétaire du produit décide des priorités lorsqu’il faut prendre cette décision. Le temps qui reste pour le sprint n’est pas la seule variable qui peut intervenir dans sa décision. Tandis que l’équipe progresse dans le sprint, l’exigence rejetée peut s’avérer moins utile pour atteindre l’objectif du sprint que l’exigence suivante qui est en cours, et même s’il reste du temps pour faire les deux dans le sprint, ne pas terminer une exigence en cours peut présenter plus de risque que ne pas terminer l’exigence rejetée.

En tout cas, prêter attention aux priorités et se coordonner au quotidien avec le propriétaire du produit durant le sprint permet à l’équipe Scrum (dont le propriétaire du produit) de rester concentrée.

L’équipe Scrum devrait toujours chercher à repousser ses limites. Si l’équipe de développement parvient systématiquement à réaliser 100 % du backlog du sprint, c’est qu’elle ne le recherche pas forcément. Terminer le plus grand pourcentage du backlog du sprint doit être l’objectif, mais il ne faut pas s’attendre à ce que l’équipe parvienne à 100 % systématiquement. Lorsque l’équipe Scrum cherche à repousser ses limites, le Scrum Master, qui se comporte comme un ingénieur en aéronautique, l’aide à trouver le moyen de réduire l’inertie pour devenir toujours plus efficace et en faire plus durant un sprint. Tant que l’équipe termine ce qu’elle a commencé durant le sprint et qu’elle améliore sa vélocité, c’est qu’elle est inscrite dans la logique d’amélioration continue propre à Scrum.

La revue du sprint – Étape 6

L’étape suivante sur la feuille de route de création de valeur est l’étape 6, la revue du sprint. Reportez-vous à la Figure 6-3. Cet évènement Scrum est un élément essentiel du processus d’évaluation et d’adaptation de Scrum, et survient au terme de tout sprint.

Pour le propriétaire du produit, l’objectif de la revue du sprint est d’obtenir un retour sur l’organisation du travail et de savoir si le produit évolue dans la bonne direction. C’est aussi une excellente opportunité pour le « talent » (l’équipe de développement) de montrer ce qu’elle a accompli, et de se montrer. Elle reçoit la reconnaissance pour ce qu’elle a accompli, mais doit aussi reconnaître ce qu’elle n’est pas parvenue à faire.

Figure 6-3 : La revue du sprint est un évènement Scrum et l’étape 6 de la feuille de route de création de valeur.

Le modèle de l’exposition empirique remonte à la nuit des temps, comme vous avez pu le lire au Chapitre 1. Toutefois, quelque part, il s’est perdu dans le management. Les pratiques agiles et Scrum l’ont remis au goût du jour bruyamment. Le processus du sprint en entier – de la planification du sprint au Scrum quotidien et maintenant à la revue du sprint et la rétrospective du sprint – tirent profit de ce modèle empirique fondé sur l’évaluation et l’adaptation.

Cette réunion, qui se tient à la fin de chaque sprint, permet de s’assurer que les parties prenantes sont complètement informées de ce qui a été réalisé durant le sprint et peuvent fournir un retour direct au propriétaire du produit, tandis que l’équipe de développement écoute. Les parties prenantes disposent d’un produit fonctionnel, « livrable ». Je vais explorer le sujet plus en détail.

Le processus de revue du sprint

La revue du sprint tient dans une timebox d’une heure par semaine du sprint, et se déroule au terme du dernier jour de ce dernier, généralement le vendredi. Si vos sprints durent une semaine, vous devrez donc y consacrer une heure le vendredi après-midi. N’oubliez pas de programmer cette heure lors de la planification du sprint.

Les participants à la revue du sprint sont toute l’équipe Scrum et les parties prenantes, selon ces règles :

Le Scrum Master : Facilite la réunion et s’assure qu’elle reste sur son sujet et qu’elle se déroule dans les temps.
Le propriétaire du produit : Passe rapidement en revue l’objectif du sprint et la mesure dans laquelle l’équipe Scrum l’a atteint, indique aux parties prenantes les éléments du backlog du produit qui ont été réalisés, et résume ce qu’il reste à faire dans la livraison.
La revue du sprint n’est pas l’endroit où le propriétaire du produit donne son retour sur une fonctionnalité qui a été terminée. C’est l’endroit où le propriétaire du produit reçoit un retour des parties prenantes sur la direction qu’elles souhaitent donner au produit. Le propriétaire du produit accepte ou rejette chaque exigence au moment où elle est terminée, et non à la fin du sprint. Le propriétaire du produit approuve les exigences avant qu’elles ne soient montrées aux parties prenantes.
L’équipe de développement : Présente et explique les exigences terminées.
Les parties prenantes : Posent des questions et donnent un retour.

Le processus débute avec l’équipe de développement, qui se prépare pour la revue. Voici quelques lignes directrices pour cette préparation :

L’équipe de développement se prépare pour la revue du sprint en y consacrant le moins de temps possible (20 minutes maximum) et sans support de présentation de l’avancement.
Aucune présentation PowerPoint ne doit être utilisée durant la revue du sprint.
L’équipe de développement devrait consacrer tout le temps qu’elle peut au développement du produit.
Seules les exigences qui ont été considérées comme « terminées » (selon la définition convenue) et approuvées par le propriétaire du produit sont montrées.
L’équipe de développement montre la version « livrable » de l’exigence, c’est-à-dire telle qu’elle fonctionne dans le monde réel.

Si vous passez du temps à montrer aux parties prenantes ce qui pourrait ou qui aurait dû être réalisé, cela signifie que vous leur faites une démonstration factice, et ce faisant vous ne rendez service à personne. Les parties prenantes n’espèrent jamais moins : elles espèrent toujours plus. En leur faisant croire que votre nouvelle version du produit fonctionne alors que ce n’est pas le cas, vous alourdissez la charge de travail du prochain sprint, car vous devrez parvenir à faire fonctionner ce que vous avez prétendu fonctionner déjà, en plus de tout ce qui a déjà été prévu. Ne montrez que les exigences terminées. Pas de démonstration truquée ! Elles prennent du temps à réaliser, un temps précieux, qui pourrait être consacré au développement.

Le retour des parties prenantes

Le retour des parties prenantes est d’une importance cruciale lors de la revue du sprint. C’est un cycle permanent de communication qui permet de garder le projet sur les rails pour aboutir à ce que les parties prenantes désirent. Si ces dernières ne peuvent dire aux membres de l’équipe de développement comment développer les exigences, elles peuvent fournir un retour sur les exigences et les fonctionnalités qu’elles veulent voir développer au propriétaire du produit, et dire dans quelle mesure les réalisations répondent aux besoins du client.

Cette boucle de retour a aussi un autre usage : l’équipe de développement reste impliquée et donc émotionnellement engagée dans le projet.

Lorsque Daniel Pink a étudié la motivation, il a découvert que l’une de ses trois composantes clés est le sens que les gens trouvent à ce qu’ils font. Montrer le dur travail de développement et être directement impliqué dans la boucle de retour permet justement cela. C’est ce qu’on appelle l’appropriation.

Le retour est un thème récurrent dans Scrum. La Figure 6-4 montre que différents niveaux de retours sont mis en œuvre dans le cadre de Scrum. Chaque fois qu’un retour arrive, il est exploité lors d’un cycle complet, étant injecté dans le backlog du produit puis dans celui d’un sprint. C’est vraiment de l’évaluation et de l’adaptation au sens propre.

Figure 6-4 : Les multiples niveaux de retour dans un projet Scrum.

Les incréments du produit

L’incrément du produit est le dernier des trois artéfacts de Scrum (j’ai déjà présenté le backlog de produit au Chapitre 3, et le backlog de sprint au Chapitre 5).

Durant un sprint, l’incrément du produit correspond à un produit fonctionnel décrété terminé par le propriétaire du produit, qui peut donc être « livré ». Il n’est que potentiellement livrable, car le propriétaire du produit peut décider qu’il ne sera livré qu’à une date ultérieure. Toutefois, il n’en est pas moins livrable aussitôt que le propriétaire du produit le souhaitera.

Un incrément du produit a été :

Développé
Testé
Intégré
Documenté

Durant la réunion de revue du sprint, l’incrément du produit est montré aux parties prenantes. Le cycle d’évaluation et d’adaptation du sprint continue, les retours sont pris en compte et traduits en exigences. Ces exigences peuvent être élaborées durant les activités d’affinage du backlog du produit, et gagnent en priorité au fil des sprints pour devenir finalement de nouveaux incréments du produit.

La revue du sprint a pour objet d’améliorer le produit. C’est ainsi que l’équipe Scrum peut parvenir à mettre en œuvre cette amélioration continue dont il a été question.

La rétrospective du sprint – Étape 7

La septième et dernière étape de la feuille de route de création de valeur est la rétrospective du sprint. Reportez-vous à la Figure 6-5. C’est un autre évènement Scrum qui se déroule au terme de chaque sprint.

Figure 6-5 : La rétrospective du sprint, la septième et dernière étape de la feuille de route de création de valeur.

L’objectif de la rétrospective du sprint est de donner une opportunité à l’équipe Scrum – le Scrum Master, le propriétaire du produit et l’équipe de développement – de passer en revue ce qui s’est bien passé lors du sprint qui vient de s’achever, et ce qui pourrait être amélioré. C’est encore une fois de l’évaluation et de l’adaptation, en mettant l’accent sur les personnes, les processus et les outils de l’équipe Scrum.

Le résultat de la rétrospective du sprint devrait être un plan d’action pour l’amélioration continue de Scrum, des personnes, des processus et des outils lors de chaque sprint. Si le cadre de Scrum est simple (trois rôles, trois artéfacts et cinq évènements, comme expliqué au Chapitre 1), et n’a pas besoin d’être remis en cause, chaque équipe Scrum présente des nuances du fait de la nature du produit, de l’organisation ou encore des méthodes de développement. Grâce au processus d’évaluation et d’adaptation, vous pouvez diriger ces tendances particulières afin de les faire converger vers les objectifs du projet.

Comme la rétrospective du sprint a besoin de retour de tous les membres de l’équipe Scrum, elle contribue à renforcer l’appropriation et le sens du travail. L’esprit d’équipe est aussi renforcé. Cela se traduit par des gains de productivité et de vélocité. C’est l’automanagement.

Il est essentiel que la rétrospective du sprint se déroule en confiance. Le point de vue de chacun doit être écouté et respecté, et rien ne doit être pris sur le plan personnel. La confiance est la clé pour que la rétrospective du sprint ne dégénère pas en discussions sans fin ou en débats politiques. Le Scrum Master joue un rôle essentiel à ce niveau.

La rétrospective du sprint peut révéler des problèmes dans l’équipe. C’est ici qu’un Scrum Master expérimenté peut faciliter l’évènement de sorte que ces questions soient traitées équitablement, sans tensions. Ce n’est pas le moment de vider son sac. C’est le moment d’élaborer un plan d’action afin de s’améliorer ensemble.

Le processus de rétrospective du sprint

La rétrospective du sprint se déroule au terme de chaque sprint, après la revue du sprint et avant la session de planification du sprint suivant. C’est souvent le dernier travail accompli le dernier vendredi de chaque sprint. Une timebox de 45 minutes est indiquée pour cet évènement.

Toute l’équipe Scrum participe, ainsi que les personnes qu’elle souhaite inviter (comme des clients ou des parties prenantes) si jamais elle juge qu’elle peut ainsi bénéficier de lumières pour s’améliorer.

En préparation de la rétrospective, chacun doit se demander comment le sprint s’est déroulé et élaborer des propositions et/ou identifier des problèmes. L’idée est de reconnaître les inefficacités internes à l’équipe et de les rectifier.

Le Scrum Master facilite la réunion, et chacun participe au même niveau. L’objet est de passer en revue le sprint qui vient de s’achever pour :

Identifier ce qui s’est bien passé durant le sprint, concernant les processus, les outils et la dynamique de l’équipe.
Rechercher et découvrir des opportunités pour s’améliorer.
Définir un plan d’action pour procéder aux améliorations.

Durant la rétrospective, n’oubliez pas d’insister sur ce qui s’est bien passé en y consacrant le temps nécessaire. Ne passez pas dessus rapidement. Il est important de se focaliser sur le positif, d’identifier ce qui va bien pour que cela continue de bien aller ! Réjouissez-vous de vos succès. Il est tout particulièrement important de reconnaître les victoires, grandes et petites, la première fois que Scrum est mis en œuvre. Un bon moyen pour conserver ce qui marche et pour éviter d’isoler les personnes durant une rétrospective du sprint, c’est de recourir à la technique du sandwich. Commencez par le positif, passez au négatif, puis terminez avec du plus positif.

Il est aussi essentiel que la discussion durant la rétrospective soit focalisée sur l’action et non sur la justification. Lorsque vous discutez de ce qui s’est mal passé et que vous entendez le terme parce que, c’est signe que la discussion prend le chemin de la justification, cherchant à savoir pourquoi quelqu’un a fait quelque chose, pour en arriver à pointer du doigt et susciter des réactions défensives. Vous devez chercher à dépasser cela avec des actions telles que « C’est l’expérience que j’ai faite, et voici ce qui pourrait mieux fonctionner à l’avenir ». N’en restez pas à « J’ai fait ainsi parce que… »

Esther Derby et Diana Larsen ont écrit un excellent livre intitulé Agile Team Retrospective : Making Good Terms Great (publié par Pragmatic Bookshelf). Vous pouvez vous y référer pour des conseils et des techniques relatives à la rétrospective du sprint et à d’autres pratiques agiles.

Dans Agile Retrospectives, Derby et Larsent pointent qu’il y a plus à faire que simplement poser les trois mêmes questions à la fin d’un sprint pour savoir ce qui s’est bien passé et identifier les améliorations à apporter. La facilitation de la rétrospective nécessite de la préparation et un sens de la stratégie pour maximiser la participation et obtenir de chacun qu’il apporte candidement le plus d’informations possible. Si vous êtes un Scrum Master, l’ouvrage est une excellente ressource pour avoir des idées d’activité et développer vos compétences en matière de facilitation.

Quoiqu’il constitue un bon point de départ si vous n’avez jamais conduit de rétrospective à ce jour, leur modèle ne consiste pas simplement à débouler dans la salle pour poser trois questions :

Qu’est-ce qui s’est bien passé ?
Qu’est-ce que vous voudriez changer ?
Comment pourrions-nous mettre en œuvre ce changement ?

Pour maximiser l’efficacité de la rétrospective, je recommande leur processus :

Plantez le décor.
C’est une réunion différente de celles auxquelles les membres de l’équipe participent généralement. L’idée de discuter à cœur ouvert des questions qui se posent dans l’équipe a tendance à mettre les gens tout de suite sur leur garde. Aussi, devez-vous élaborer les règles d’une communication productive et clarifier les objectifs dès les premiers instants.
Récupérez les informations.
Prendre des décisions sur la base de données éparses, superficielles ou mauvaises peut faire plus de mal que de bien. Vous devez identifier les sujets d’importance, solliciter la mémoire de tous, et cerner les expériences qu’il faut adresser. Vous cherchez à savoir non seulement ce que les gens pensent, mais aussi ce qu’ils ressentent.
Générez des idées.
Les grandes questions étant maintenant sur la table, que faire ? Nombre d’équipes ne parviennent pas à tirer les vrais bénéfices de la rétrospective du sprint parce qu’elles se contentent de réunir l’information sans rien en faire. Tout comme les meilleures solutions sont élaborées par des équipes qui s’auto-organisent, les meilleures idées sur ce qui s’est passé viennent d’équipes qui prennent le temps d’explorer ce que les informations veulent dire.
Décidez quoi faire.
Seule l’action peut apporter le changement concernant l’adaptation. L’action a besoin d’être planifiée. Décider quoi faire permet à l’équipe de se focaliser sur le futur – le prochain sprint.
Clôturez la rétrospective.
Clôturer donne l’opportunité de faire « le Scrum de la rétrospective » en se livrant à des activités pour évaluer la manière dont la rétrospective s’est déroulée et identifier des manières de l’améliorer. Cela encourage chacun à donner son appréciation.

Chaque aspect de la rétrospective peut être facilité par un nombre d’activités de groupe pour susciter des réflexions personnelles et des discussions dans le groupe, par exemple les trois pièces, les cinq pourquoi, les objectifs SMART, la Lecture de la température, le Radar de l’équipe, ou Glad-Sad-Mad (Content-Triste-Furieux).

Pour stimuler la discussion lors d’une rétrospective, cadrez-la en posant des questions comme :

Qu’est-ce qui nous empêche de passer notre vélocité de 36 à 38 ?
Chacun dispose-t-il des outils dont il a besoin pour faire le boulot ?
Des obstacles se présentent-ils de manière récurrente ?
Notre Scrum quotidien est-il assez efficace pour identifier les obstacles et déterminer les priorités du jour ?
Des compétences font-elles défaut à notre équipe, et comment pouvons-nous les acquérir ?

Certaines équipes Scrum auront besoin d’être amadouées et poussées pour s’impliquer vraiment. Dans un premier temps, leurs membres peuvent être réticents à exprimer vraiment ce qu’ils pensent. D’autres équipes sont tout le contraire. Leurs membres veulent tous prendre la parole simultanément, pour partager plein d’idées et d’expériences. C’est ici qu’un Scrum Master sensible et proactif (facilitateur) montre qu’il sait s’adapter à chacun de ces types de groupes, ou tout type intermédiaire, pour obtenir les meilleurs résultats.

Les résultats de la rétrospective du sprint devraient être rajoutés dans le backlog du produit en tant qu’éléments « d’amélioration ». L’équipe Scrum devrait convenir d’en injecter ainsi au moins un à chaque sprint. Intégrez au moins un élément prioritaire dégagé lors de la rétrospective au sprint suivant (il peut aussi bien provenir d’une rétrospective antérieure). Après tout, pourquoi attendre ? L’objet est d’évaluer et d’adapter, alors ne traînez pas pour adapter !