Les douze principes

Le rythme soutenable

Le huitième principe du Manifeste demande un rythme de développement que tous puissent tenir indéfiniment. Il va contre une habitude ancienne des projets, celle de rattraper un retard par des soirées et des week-ends. Il pose aussi une question de vocabulaire, puisque la méthode agile la plus répandue appelle ses cycles de travail des « sprints ».

Huit semaines de soirées

Un éditeur de logiciel de paie doit intégrer une nouvelle règle légale applicable au 1^er janvier. Début novembre, l'équipe constate qu'elle est en retard. Le directeur demande un « effort exceptionnel » : pendant huit semaines, les sept développeurs restent le soir et viennent deux samedis par mois. La version sort à la date prévue.

En janvier, les clients signalent des erreurs sur les bulletins de paie. L'équipe passe février et mars à les corriger. Au printemps, deux développeurs expérimentés démissionnent. La version suivante, promise pour juin, sort en octobre.

« Nous avons tenu la date », rappelle le directeur lors du bilan.

« Nous avons tenu la date, répond la responsable de l'équipe, et nous avons passé le trimestre suivant à corriger ce que nous avions écrit à dix heures du soir. Sur l'année, nous avons livré moins que si nous avions décalé la sortie de trois semaines. »

Cette scène est inventée, mais beaucoup d'équipes la reconnaîtront. Elle montre ce que le huitième principe cherche à éviter : un gain immédiat, bien visible, payé plus tard par une perte plus grande et plus difficile à attribuer.

Ce que dit le principe

Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

Manifeste agile, principe 8

Le mot « soutenable » traduit l'anglais sustainable : qui peut être soutenu dans la durée. Le rythme soutenable est donc la cadence de travail qu'une équipe peut conserver mois après mois sans s'user.

La seconde phrase nomme trois groupes. Les commanditaires sont ceux qui financent le projet et en décident. Les développeurs le réalisent, et les utilisateurs s'en serviront. Le mot « ensemble » indique que le rythme les concerne tous. Les commanditaires doivent pouvoir financer et suivre le projet sans à-coups. Les utilisateurs doivent pouvoir absorber les versions successives, se former et donner leur avis. Le rythme n'est donc pas seulement une affaire d'horaires des développeurs, même si c'est la lecture la plus courante.

L'adverbe « indéfiniment » fixe l'horizon. Un logiciel utile vit des années, et l'équipe qui le fait évoluer n'a pas de ligne d'arrivée. Une cadence qui ne tient que jusqu'à la prochaine échéance ne répond pas au principe.

L'adjectif « constant » ajoute la régularité. Une équipe qui produit à peu près la même quantité de travail à chaque itération (chaque période courte de durée fixe) permet à tous de prévoir. Une équipe qui alterne les semaines d'épuisement et les semaines de récupération rend toute prévision impossible.

De la semaine de 40 heures au « travail plein d'énergie »

Le principe vient directement d'Extreme Programming (XP). Dans Extreme Programming Explained (1999), Kent Beck range la « semaine de 40 heures » parmi les douze pratiques de la méthode. La règle qu'il donne est simple : on ne fait pas d'heures supplémentaires deux semaines de suite. Une semaine chargée peut arriver. Si une seconde semaine semble nécessaire, c'est que le problème se trouve ailleurs, dans le plan ou dans les estimations, et que les heures supplémentaires ne le résoudront pas.

Le nombre de 40 n'avait rien de sacré pour Beck, qui voulait surtout des développeurs frais et attentifs. La communauté XP a d'ailleurs vite préféré l'expression « rythme soutenable », moins liée à un total d'heures. Dans la seconde édition de son livre (2004), Beck rebaptise la pratique Energized Work, que l'on peut traduire par « travail plein d'énergie » : ne travailler que le nombre d'heures pendant lesquelles on reste réellement productif, et que l'on peut tenir.

L'idée est bien plus ancienne que le logiciel. En 1926, Henry Ford avait adopté dans ses usines la semaine de cinq jours et de quarante heures, en pariant que la production n'en souffrirait pas. XP l'a transposée à un travail intellectuel, où les effets de la fatigue sont moins visibles que sur une chaîne.

Ce que l'on sait des longues heures

La recherche fournit quelques repères, presque tous extérieurs au logiciel. L'économiste John Pencavel a repris en 2015 des données recueillies pendant la Première Guerre mondiale dans des usines britanniques de munitions. En dessous d'un certain seuil, la production augmentait en proportion des heures travaillées. Au-delà d'environ 49 heures par semaine, chaque heure supplémentaire rapportait de moins en moins, au point que la production d'une semaine de 70 heures différait peu de celle d'une semaine de 56 heures. Il s'agissait d'un travail manuel, il y a un siècle. La transposition au travail de bureau est plausible, mais cette étude ne la démontre pas.

À l'hôpital, Christopher Landrigan et ses collègues ont comparé en 2004 deux organisations du travail d'internes en soins intensifs. Avec le planning traditionnel, qui comportait des gardes de 24 heures et plus, les internes commettaient environ 36 % d'erreurs médicales graves de plus qu'avec un planning limitant les heures consécutives. La fatigue coûte donc en qualité, dans un métier où les erreurs sont comptées avec soin.

Pour le logiciel, on dispose surtout de témoignages. Edward Yourdon a décrit dans Death March (1997) les projets menés à marche forcée. En 2004, un billet anonyme signé « EA Spouse » a fait connaître au public les semaines interminables imposées dans l'industrie du jeu vidéo. Ces récits concordent, mais ils ne valent pas une mesure.

Un petit calcul aide à comprendre pourquoi le gain espéré peut disparaître. Une équipe de cinq personnes travaille 35 heures par semaine, soit 175 heures au total. On lui demande de passer à 50 heures, soit 250 heures : sur le papier, sa capacité augmente de 43 %. Supposons, pour raisonner, que la fatigue réduise de 20 % ce que chaque heure produit. Les 250 heures n'en valent plus que 200, et le gain réel tombe à 14 %. Si une partie des semaines suivantes sert à corriger les erreurs commises tard le soir, il peut devenir nul ou négatif. Les 20 % sont ici une hypothèse et non une mesure. Le calcul montre seulement que le gain apparent et le gain réel peuvent être très éloignés.

Dans un logiciel, la fatigue a un second effet. Une équipe pressée prend des raccourcis : elle saute des tests et copie du code au lieu de le réorganiser. Ces raccourcis forment la dette technique, c'est-à-dire l'ensemble des défauts de conception qui rendent chaque modification future plus longue (voir L'excellence technique et la simplicité). Le rythme forcé d'un trimestre ralentit ainsi les trimestres suivants, comme dans la scène du logiciel de paie.

« Sprint », un mot mal choisi

Scrum appelle « sprint » son itération, une période d'un mois au plus au terme de laquelle l'équipe livre un incrément, c'est-à-dire un ajout au produit qui fonctionne. Le mot figure dans la méthode depuis sa première présentation publique par Ken Schwaber, en 1995, et il appartient au vocabulaire sportif que Scrum a adopté avec son nom, emprunté au rugby.

En athlétisme, un sprint est un effort maximal sur une courte distance, suivi d'une récupération. Dans Scrum, les sprints s'enchaînent sans pause : le suivant commence dès que le précédent se termine. Pris au pied de la lettre, le mot décrit donc une équipe qui courrait un cent mètres toutes les deux semaines, toute l'année. Ce n'est pas l'intention de la méthode. Le guide Scrum précise que travailler par sprints à un rythme soutenable améliore la concentration et la régularité de l'équipe. L'image juste serait plutôt celle de la course de fond, où l'on cherche l'allure que l'on peut garder jusqu'au bout.

Le malentendu a pourtant des effets réels. Dans beaucoup d'organisations, la fin de chaque sprint est vécue comme une échéance à tenir coûte que coûte. La vélocité, qui mesure la quantité de travail terminée par sprint et sert à prévoir, devient un objectif à augmenter. Une mesure faite pour connaître le rythme de l'équipe se transforme alors en moyen de pression. Le corpus Scrum revient sur ces points dans Le Sprint.

Tenir le rythme en pratique

Un rythme soutenable se construit par quelques habitudes de planification.

La première est de planifier d'après ce que l'équipe a réellement fait. Beck et Martin Fowler, dans Planning Extreme Programming (2000), appellent cela « le temps qu'il a fait hier » : pour la prochaine itération, on ne prévoit pas plus de travail que ce qui a été terminé pendant la précédente. La prévision repose sur un constat et cesse de dépendre de l'optimisme.

La deuxième est d'ajuster le contenu plutôt que les heures. Beck décrit un projet par quatre variables : le coût, le délai, la qualité et le périmètre. Quand le délai est fixe et que l'équipe ne grossit pas, il reste à choisir entre réduire le périmètre et dégrader la qualité. Le rythme soutenable suppose que l'on choisisse le périmètre, en retirant les fonctions les moins utiles.

La troisième est de garder de la marge. Tom DeMarco soutient dans Slack (2001) qu'une organisation occupée à 100 % ne peut plus absorber un imprévu ni s'améliorer. Limiter le travail en cours (souvent abrégé en WIP, pour work in progress), c'est-à-dire le nombre de sujets ouverts en même temps, va dans le même sens (voir Kanban et le Lean logiciel).

Hors du logiciel : le festival et ses bénévoles

Limites et pièges

Le rythme soutenable ne se résume pas à un nombre d'heures. Les durées légales diffèrent selon les pays, les personnes n'ont pas toutes la même endurance, et quarante heures hachées par les interruptions fatiguent plus que quarante heures de travail suivi. La charge mentale, les astreintes et le nombre de sujets menés de front comptent autant que l'horaire.

Il existe de vraies urgences. Une panne en production ou une échéance légale justifient un effort ponctuel, et la règle de Beck l'admet. Le problème commence quand l'exception devient le régime ordinaire et que chaque version est déclarée « exceptionnelle ».

Le principe peut aussi servir de prétexte. L'invoquer pour refuser tout engagement de date ou tout effort inhabituel le déforme : le texte parle d'un rythme « constant », ce qui suppose une production régulière sur laquelle les autres peuvent compter.

L'équipe ne peut pas le respecter seule. Si les commanditaires fixent à la fois le périmètre, la date et le budget, il ne reste que les heures et la qualité pour absorber les écarts. C'est le sens du mot « ensemble » dans le principe, et c'est le point où il est le plus souvent ignoré.

Les méthodes agiles peuvent enfin intensifier le travail qu'elles prétendaient apaiser. Des sprints enchaînés sans respiration et une vélocité érigée en objectif produisent une pression continue, surtout quand la réunion quotidienne sert à surveiller. Ron Jeffries, l'un des signataires, a décrit cette dérive sous le nom de « Dark Scrum » (voir Être agile ou faire de l'agile). Le Lean connaît la même critique, et nomme muri la surcharge imposée aux personnes et aux machines (voir Muda, mura, muri).

Les preuves disponibles viennent surtout de l'industrie et de l'hôpital. Leur application au développement logiciel est raisonnable, mais elle reste peu mesurée (voir Que valent les preuves ?).