L'organisation

Le swarming : finir ensemble une chose à la fois

Une équipe où chacun avance sur son propre sujet donne l'impression d'aller vite et termine peu de choses. Le pattern Swarming d'A Scrum Book propose l'inverse : toute l'équipe se concentre sur un seul élément jusqu'à ce qu'il soit terminé, puis passe au suivant. L'idée vient du flux pièce à pièce de Toyota, et elle a ses limites.

Cinq chantiers ouverts et rien de terminé

Une équipe de cinq développeurs construit l'application de suivi des tournées d'une entreprise de livraison de repas à domicile. Elle travaille en Sprints, des périodes de durée fixe qui durent ici deux semaines. Au début du Sprint, chacun a pris un élément de la liste : le plan des tournées, la signature du client, les alertes de retard, l'export pour la paie et la gestion des régimes alimentaires.

La veille de la Sprint Review, la réunion où l'équipe montre son résultat aux parties prenantes, la Product Owner, qui décide de l'ordre des éléments à construire, fait le tour des bureaux : « Qu'est-ce que je peux montrer demain aux responsables de tournée ? » Lucas répond : « Le plan des tournées est codé, il reste les tests. » Amel ajoute : « Les alertes sont presque finies, j'attends que Lucas relise mon code. » Les trois autres sont dans la même situation. Cinq éléments sont « presque finis » et aucun ne respecte la Definition of Done, la définition commune de ce qu'est un travail terminé. La Product Owner n'a rien à montrer.

Le mot swarming vient de swarm, l'essaim. Il désigne une équipe qui se rassemble sur un même travail au lieu de se disperser.

Le pattern Swarming: One-Piece Continuous Flow

A Scrum Book (2019) décrit Scrum sous forme de patterns : chacun expose un problème récurrent, les forces en jeu et une solution tirée de l'expérience. Le pattern Swarming: One-Piece Continuous Flow (« essaimage : flux continu pièce à pièce ») porte une étoile : les auteurs y voient le cœur d'une bonne solution sans prétendre qu'elle soit la seule. Il part d'un partage des rôles. Le Product Owner ordonne la liste de ce qu'il faut construire (le Product Backlog) pour obtenir la plus grande valeur. Les développeurs, eux, organisent leur travail dans le Sprint pour que la production s'écoule le mieux possible.

Le problème. Travailler sur trop de choses à la fois réduit fortement l'efficacité de chacun et la vélocité de l'équipe (la quantité de travail qu'elle termine par Sprint), parfois jusqu'à zéro. Quand chacun s'occupe de son propre sujet, les membres ne s'entraident pas et n'apprennent pas les uns des autres.

Les forces. Les préférences de chacun et les obstacles du quotidien dispersent les efforts. Il en résulte beaucoup de travail en cours (work in process), c'est-à-dire de travail commencé et non terminé. Dans une usine, ce sont des pièces à moitié faites qui occupent de la place et immobilisent de l'argent. Dans un bureau, ce stock ne se voit pas, mais il retarde tout autant.

Un développeur qui travaille seul sur un élément préfère construire plutôt que tester, et les tests sont repoussés. Si plusieurs éléments prennent du retard, aucun n'est terminé à la fin du Sprint. Mener plusieurs choses de front donne pourtant une impression de vitesse et répond au souhait de la direction de voir chacun occupé. Enfin, les éléments d'un produit complexe dépendent les uns des autres, ce qui limite le travail en sous-groupes indépendants. Les développeurs veulent souvent travailler chacun de leur côté pour ne pas se gêner, ce que le livre tient pour le symptôme de pratiques techniques insuffisantes.

La solution. L'équipe concentre le plus d'effort possible sur un seul élément du Product Backlog et termine tout le travail connu sur cet élément au plus vite. La personne qui prend l'élément en devient le « Capitaine ». Tous les autres l'aident s'ils le peuvent, et personne ne l'interrompt. Dès que l'élément est terminé, celui qui prend le suivant devient Capitaine à son tour.

Le livre précise deux points. Se concentrer sur un élément ne revient pas à enchaîner des phases : sur l'élément en cours, quelques minutes de réalisation alternent avec un test, qui renvoie à un peu d'analyse, jusqu'à ce que tout soit terminé. Traiter une phase à la fois pour tous les éléments serait une autre manière d'éviter le travail d'équipe. Ensuite, l'efficacité de chaque individu cesse d'être le critère, et le livre affirme qu'un peu de marge dans l'emploi du temps de chacun accélère l'ensemble.

Finir une chose à la fois : un calcul simple

Prenons trois éléments, A, B et C, qui demandent chacun deux jours de travail à l'équipe entière. L'équipe peut les traiter l'un après l'autre, ou avancer d'un jour sur chacun à tour de rôle.

Dans les deux cas, tout est terminé au sixième jour. Mais dans le premier, A est utilisable dès le deuxième jour, et les éléments sont terminés en moyenne au bout de quatre jours au lieu de cinq. Si une urgence arrête le travail au soir du troisième jour, l'équipe a un élément terminé et un autre à moitié fait dans le premier cas, et trois moitiés dans le second.

Ce calcul suppose que passer d'un sujet à l'autre ne coûte rien, ce qui est optimiste. Le livre renvoie à la règle empirique de Gerald Weinberg (Quality Software Management, 1992), pour qui mener deux projets de front fait perdre environ 20 % du temps en changements de contexte, et davantage au-delà. Il s'agit de l'estimation d'un praticien et non d'une mesure.

Du flux pièce à pièce de Toyota au travail en cours limité

Le sous-titre du pattern renvoie au one-piece flow de l'industrie : chaque pièce passe d'une étape à la suivante sans attendre dans un lot. Le livre cite Taiichi Ohno, qui raconte dans Toyota Production System (édition anglaise de 1988) comment, en 1947, Toyota a disposé les machines en lignes parallèles ou en L pour qu'un ouvrier en conduise trois ou quatre le long du parcours de fabrication. Les ouvriers qualifiés ont résisté, parce qu'ils devaient devenir polyvalents. L'article du corpus Lean sur le flux continu et la pièce à pièce détaille ce principe.

Le swarming transpose l'idée à une équipe. La « pièce » est l'élément du Product Backlog, et le « lot » est l'ensemble des éléments commencés en même temps. La même résistance s'y retrouve, puisque chacun doit sortir de sa spécialité pour aider à terminer.

D'autres approches obtiennent un effet voisin par une règle chiffrée. La méthode Kanban de David J. Anderson (2010) fixe pour chaque étape un nombre maximal d'éléments en cours. Le swarming est le cas extrême où l'équipe se donne une limite de un.

Le Guide Scrum de 2020 ne mentionne ni le swarming ni la limitation du travail en cours. Il laisse aux développeurs le soin de décider comment ils transforment les éléments choisis en résultat terminé, et il leur demande d'adapter leur plan chaque jour. Le swarming est donc une pratique compatible avec le Guide, sans être une règle de Scrum. Autre écart de vocabulaire : le livre parle de « Development Team », terme que le Guide a remplacé en 2020 par « Developers ».

Comment s'y prendre

Le livre donne quelques leviers. L'équipe prend l'élément placé en tête de son tableau et s'organise autour de lui. Elle se donne un objectif de Sprint clair, qui la rassemble. L'organisation, de son côté, valorise l'équipe plutôt que les exploits individuels : les auteurs recommandent de limiter les récompenses personnelles et de combattre la culture du héros, heures supplémentaires comprises.

Le Daily Scrum, la réunion quotidienne de quinze minutes où les développeurs ajustent leur plan, est le moment où le swarming se décide. La formule du pattern laisse une marge, puisque chacun aide le Capitaine « s'il le peut ». Quand un élément ne peut pas occuper tout le monde, ceux qui ne peuvent pas aider prennent l'élément suivant, et l'équipe garde le nombre de chantiers ouverts aussi bas que possible.

Limites et pièges

Tout travail ne se divise pas. Fred Brooks l'a rappelé dans The Mythical Man-Month (1975) avec l'exemple de la grossesse, qui dure neuf mois quel que soit le nombre de femmes mobilisées. Cinq personnes sur un petit élément se gênent. La réserve « s'il le peut » le reconnaît, sans dire à partir de quand l'aide devient un encombrement : c'est à l'équipe d'en juger.

Le swarming suppose aussi des compétences partagées et des pratiques qui permettent à plusieurs personnes de modifier le même ouvrage sans se gêner. Une équipe de spécialistes qui ne peuvent pas s'entraider n'en tirera rien au début, et la polyvalence s'acquiert lentement. Travailler ensemble toute la journée fatigue, et certaines personnes ont besoin de temps seules pour réfléchir.

Vu de l'extérieur, trois personnes devant le même écran ressemblent à du gaspillage. Si la direction juge l'équipe au taux d'occupation de chacun, elle défera vite ce que l'équipe a mis en place.

Restent les chiffres. Le livre affirme que cette pratique a doublé la productivité de toutes les équipes de la société danoise Systematic et qu'elle a ramené les cycles de livraison de Citrix Online de 42 mois à moins de 10. Ces résultats viennent de communications signées par des acteurs de ces transformations, où bien d'autres choses changeaient en même temps. Ils ne permettent pas d'attribuer le gain au swarming seul. L'article Critiques et état des preuves revient sur ce type d'affirmation.