Le flux de valeur

Rendre le travail visible

Une équipe qui ne voit pas où en est son travail décide sur des impressions, et ces impressions diffèrent d'une personne à l'autre. Quatre patterns d'A Scrum Book décrivent comment afficher l'information utile, suivre le Sprint au jour le jour et distinguer ce qui informe de ce qui appelle une action immédiate. Aucun de ces outils n'est exigé par le Guide Scrum, et chacun peut se retourner contre l'équipe s'il sert à la surveiller.

Dix secondes devant un tableau blanc

Dans le poste de soins d'un service de chirurgie, un grand tableau blanc occupe un mur. Chaque ligne correspond à une chambre et indique le jour de l'intervention, les examens attendus et la date de sortie prévue. L'infirmière qui prend son poste, le médecin de passage et le cadre du service savent en dix secondes quels lits vont se libérer et quel patient attend encore un scanner. Personne n'a réuni l'équipe ni ouvert un logiciel pour obtenir ce résultat.

Les équipes Scrum cherchent le même effet pour leur propre travail. Le Guide Scrum fait de la transparence le premier pilier de l'empirisme : on ne peut inspecter et adapter que ce que l'on voit. A Scrum Book consacre quatre patterns à cette question.

Information Radiator : l'information qui vient à vous

Le pattern Information Radiator (radiateur d'information) part d'un constat : une organisation privée d'information fiable et récente prend de mauvaises décisions. Les auteurs l'illustrent par l'accident de la navette Challenger, en 1986 : la commission d'enquête a relevé que des avertissements sur un défaut connu des propulseurs avaient été ignorés.

Plusieurs forces s'opposent au partage. Garder pour soi ce que l'on sait demande moins d'effort que de le diffuser, et un développeur occupé considère vite les comptes rendus comme une charge étrangère à son métier. Les réunions d'avancement coûtent du temps. Un excès de données produit le même effet qu'un manque, car les lecteurs finissent par ne plus regarder. Enfin, l'information perd de sa valeur avec le temps : apprise trop tard, elle ne sert qu'à constater que des décisions ont été prises sans elle.

La solution consiste à entretenir ensemble des supports physiques qui gardent l'information visible de toutes les parties prenantes. Le livre donne quelques règles de construction :

• concevoir l'affichage avec ceux qui ont besoin de l'information, en acceptant que la première version soit mauvaise ;
• supprimer sans regret ce qui ne sert pas ;
• préférer un affichage simple et fait à la main, peu coûteux à tenir à jour ;
• le placer là où l'on ne peut pas éviter de le voir ;
• le faire évoluer, faute de quoi il devient un papier peint que plus personne ne lit.

Les auteurs sont sévères envers les outils numériques, qu'ils qualifient de « réfrigérateurs d'information » : l'information y est conservée, mais il faut aller la chercher. Ils ajoutent deux exigences. Il faut avoir le courage d'afficher les mauvaises nouvelles, et ne jamais se servir d'un affichage pour désigner un coupable.

Le livre cite comme exemples le tableau Scrum, le graphique d'avancement du Sprint et la liste des obstacles tenue par le Scrum Master (Impediment List). Il rattache l'idée au « contrôle visuel » du système de production Toyota et attribue l'expression information radiator à Alistair Cockburn, qui l'a forgée en 2001.

Scrum Board : le plan du Sprint sur un mur

Le pattern Scrum Board (tableau Scrum) se place juste après le Sprint Planning. Les développeurs ont un plan, le Sprint Backlog, et chacun avance sur sa partie. Le problème est qu'ils risquent de perdre de vue collectivement le Sprint Goal, l'objectif du Sprint. Les auteurs empruntent aux militaires l'image du « brouillard de la guerre », qui naît moins d'un manque d'information que d'un excès de rapports disparates dans une situation qui change vite. Des personnes de métiers différents collaborent mal si elles ne voient pas comment leurs tâches se rattachent à l'objectif commun.

La solution est un tableau qui représente le Sprint Backlog et son évolution pendant le Sprint. Les développeurs le tiennent à jour et en sont les seuls propriétaires. Il relie les tâches aux éléments du Product Backlog (les PBI, pour Product Backlog Items), et ces éléments au Sprint Goal. Le livre précise que Scrum n'impose aucun format et décrit un exemple : une ligne par élément, et des colonnes « à faire », « en cours » et « terminé » dans lesquelles on déplace des notes adhésives. L'élément lui-même ne passe dans la dernière colonne que lorsque toutes ses tâches sont finies et qu'il respecte la Definition of Done. Les auteurs conseillent de tenir le Daily Scrum devant le tableau.

Les auteurs distinguent ce tableau d'un tableau Kanban, qui suit chaque élément à travers tous ses états jusqu'au client, avec une limite de travail en cours par état. Ils rappellent aussi qu'afficher un tableau ne suffit pas à « faire du Scrum » : taper dans un ballon dans un parc ressemble au football sans en être.

Sprint Burndown Chart : la pente qui reste à descendre

Le pattern Sprint Burndown Chart (graphique d'avancement du Sprint) répond à une tension. La prévision faite au Sprint Planning comporte trop d'inconnues pour valoir garantie, mais elle a créé des attentes chez les parties prenantes. Les développeurs ont besoin de savoir, presque chaque jour, s'ils sont en voie de la tenir. S'ils ont surestimé leur capacité, il faut prévenir tôt. S'ils l'ont sous-estimée, la Scrum Team doit décider quoi faire de la capacité disponible.

La solution est un graphique qui porte en ordonnée le travail restant estimé et en abscisse les jours du Sprint. La pente de la courbe donne une indication immédiate. On trace souvent une ligne de référence droite entre le total initial et zéro : une courbe nettement au-dessus annonce un Sprint inachevé, une courbe nettement au-dessous annonce de la marge. Les auteurs notent que la descente réelle est rarement linéaire et qu'une comparaison avec les Sprints précédents serait plus juste. D'après le livre, Ken Schwaber a décrit ce graphique en mai 2001, après l'avoir inventé chez Fidelity Investments.

Le pattern recommande de compter les éléments terminés et non les tâches. La courbe ne descend que lorsqu'un élément atteint l'état Done, de la valeur de son estimation d'origine, et elle remonte si l'équipe découvre du travail imprévu. On ne retire rien pour un élément à moitié fait, car une équipe peut achever beaucoup de tâches sans livrer aucune valeur. Le livre insiste sur un dernier point : le graphique appartient aux développeurs, il a été conçu pour eux et non pour la hiérarchie, et il gagne à être dessiné à la main.

Visible Status : quand l'affichage doit déclencher une action

Le pattern Visible Status (état visible) traite d'une faiblesse des radiateurs d'information : on s'y habitue. Les auteurs rappellent que l'attention portée à un but rend aveugle au reste, et citent l'expérience de Daniel Simons et Christopher Chabris (1999), dans laquelle des spectateurs occupés à compter des passes de ballon ne remarquent pas une personne déguisée en gorille qui traverse la scène. Ils racontent le cas d'une équipe qui regardait chaque matin son burndown, puis appliquait son plan sans rien changer, même quand la courbe restait plate. C'est, écrivent-ils, le message d'entretien que l'on ignore pendant des mois sur le tableau de bord d'une voiture, alors que le voyant d'huile fait arrêter le véhicule sur-le-champ. Une équipe a besoin des deux sortes de signaux.

La solution est un indicateur d'état qui exige une action dès qu'une grandeur sort de la tolérance admise : une lumière rouge, un mot qui alerte ou un blocage du poste de travail. Cela suppose que l'équipe ait discuté de ce qu'elle appelle l'état normal, qu'elle sache quoi faire quand le signal se déclenche et de combien de temps elle dispose. Les indicateurs doivent rester très peu nombreux, et l'équipe retire ceux qui ne lui servent plus. L'action peut être fixée d'avance : corriger immédiatement un défaut, ou déclencher la procédure d'urgence décrite dans l'article sur la protection du Sprint quand le Sprint s'écarte trop de son plan.

Un cabinet médical offre un exemple simple de la différence. La feuille de relevé collée sur le réfrigérateur à vaccins est un radiateur d'information : elle montre l'historique des températures à qui veut le lire. L'alarme qui sonne quand la température sort de la plage de +2 °C à +8 °C est un état visible, et la consigne affichée à côté dit quoi faire. Dans une équipe de développement logiciel, l'équivalent courant est une lampe qui passe au rouge quand les tests automatiques échouent. Une équipe peut convenir que, tant que la lampe est rouge, personne n'intègre de nouvelle modification et que l'auteur de la dernière s'en occupe aussitôt.

Le pattern vient lui aussi de Toyota, où la corde andon permet à un opérateur de signaler un défaut et d'obtenir de l'aide, jusqu'à l'arrêt de la ligne si le problème persiste (voir l'andon et le poka-yoke). Les auteurs y joignent une mise en garde : celui qui se sert de ces indicateurs pour désigner « la meilleure équipe » devrait y réfléchir à deux fois.

Ce que dit le Guide Scrum 2020

• Le Guide ne prescrit ni tableau ni graphique. Il demande que le Sprint Backlog soit une image très visible et en temps réel du travail que les développeurs prévoient d'accomplir, assez détaillée pour qu'ils inspectent leur avancement au Daily Scrum.
• Il mentionne les burn-downs, les burn-ups et les diagrammes de flux cumulés comme des pratiques utiles pour prévoir l'avancement, en ajoutant qu'elles ne remplacent pas l'empirisme : dans un environnement complexe, seul ce qui s'est déjà produit peut fonder une décision.
• L'édition 2017 demandait à l'équipe de développement de suivre le travail restant au moins à chaque Daily Scrum. L'édition 2020, moins prescriptive, a retiré cette phrase.
• Le livre écrit « Development Team » et « ScrumMaster » ; le Guide 2020 dit « Developers » et « Scrum Master ». La liste des obstacles (Impediment List) est un pattern du livre et non un artefact du Guide.

Limites et pièges

Le premier piège est l'affichage périmé. Un tableau qui n'est plus à jour trompe davantage qu'une absence de tableau, parce qu'on continue de s'y fier.

Le deuxième tient au support. Le livre, paru en 2019, raisonne pour une équipe réunie dans une même pièce. Une équipe répartie sur plusieurs sites utilise un tableau numérique (voir les équipes stables et réunies). Les critères des auteurs servent alors à juger l'outil : chacun voit-il l'ensemble d'un seul regard, et peut-on le manipuler à plusieurs ?

Le troisième est la surveillance. Un burndown consulté par un responsable pour comparer des équipes ou évaluer des personnes cesse de renseigner, car chacun se met à soigner la courbe. C'est le mécanisme de la loi de Goodhart. Le pattern sur l'esprit du jeu range d'ailleurs parmi les trahisons de Scrum l'usage d'un outil de suivi pour noter les individus.

Ces recommandations viennent enfin de l'expérience de praticiens. Le livre s'appuie sur des travaux de psychologie de l'attention pour justifier les signaux d'alerte, mais il ne cite pas d'étude contrôlée montrant qu'un tableau ou un burndown améliore les résultats d'une équipe. L'article critique du corpus revient sur ce point.