Méthodes et pratiques

L'agilité hors du logiciel

Le Manifeste agile parle de logiciels à chaque ligne. On s'en réclame pourtant aujourd'hui dans des salles de classe, des services de marketing, des directions des ressources humaines, des administrations et jusque dans des familles. Certaines de ces transpositions gardent le mécanisme d'origine, fait de cycles courts et de retours fréquents. D'autres n'en gardent que le mot.

Une classe de chimie aux Pays-Bas

Au début des années 2010, Willy Wijnands enseigne la chimie à l'Ashram College d'Alphen aan den Rijn, aux Pays-Bas. Il entend parler de Scrum, le cadre de travail le plus répandu dans les équipes de développement (voir Scrum en bref), et décide de l'essayer avec ses élèves. Avec d'autres enseignants, il en tire une adaptation qu'il nomme eduScrum et dont les règles sont rassemblées dans un guide.

Le partage des rôles y est net. L'enseignant fixe le pourquoi et le quoi : les objectifs d'apprentissage, et les critères qui diront s'ils sont atteints. Les élèves décident du comment. Ils forment des équipes de quatre à six, et chaque équipe découpe le travail en tâches qu'elle affiche sur un tableau à trois colonnes (à faire, en cours et terminé). Un élève, le capitaine, veille à ce que ce tableau soit à jour. Chaque cours commence par un point de cinq minutes, debout devant le tableau. Le travail est organisé en sprints, c'est-à-dire en périodes de durée fixe, qui durent ici environ sept semaines. Le sprint comporte plusieurs revues du travail produit et s'achève par une rétrospective, un bilan où l'équipe examine sa manière de travailler et décide de ce qu'elle changera.

Dans cette classe, le programme reste fixé par l'institution, ce qui distingue la situation de celle d'une équipe de développement dont le client change d'avis.

Les preuves d'efficacité sont minces. On dispose surtout de témoignages d'enseignants. En 2017, huit enseignants d'une université publique des États-Unis, réunis autour de Timothy Krehbiel, ont publié un « manifeste agile pour l'enseignement et l'apprentissage » après plus de deux ans d'essais dans leurs propres cours. Ils rapportent des étudiants plus engagés et des travaux de meilleure qualité, d'après leur expérience et un questionnaire rempli par les étudiants. Ce sont des résultats déclaratifs, obtenus par des enseignants convaincus. À notre connaissance, aucun essai comparatif solide n'a mesuré l'effet de ces méthodes sur les apprentissages.

Un texte écrit pour des logiciels

Il faut relire le Manifeste pour mesurer la distance à franchir. Son titre complet est « Manifeste pour le développement Agile de logiciels », et sa première phrase délimite son objet :

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.

Manifeste pour le développement agile de logiciels (2001), texte intégral

La deuxième valeur s'énonce « Des logiciels opérationnels plus qu’une documentation exhaustive », et le septième principe précise : « Un logiciel opérationnel est la principale mesure d’avancement. » Transposer le texte oblige donc à trouver, dans chaque métier, ce qui tient lieu de logiciel opérationnel. Pour une classe, ce peut être un exercice réussi. Pour un service administratif, c'est un formulaire qu'un usager parvient à remplir. Quand on ne trouve aucun équivalent, la transposition a peu de chances de dépasser le vocabulaire.

Deux précisions historiques aident à comprendre pourquoi le mot circule si facilement. La première est que l'agilité logicielle doit elle-même beaucoup à l'industrie. L'article de Hirotaka Takeuchi et Ikujiro Nonaka dont Scrum tire son nom, paru en 1986, décrivait la conception de photocopieurs, d'appareils photo et d'automobiles.

La seconde est que le mot « agile » existait dans le management avant 2001. En 1991, un rapport de l'Iacocca Institute de l'université Lehigh, dirigé par Roger Nagel et Rick Dove, lançait l'expression « agile manufacturing ». L'agilité y désignait la capacité d'une entreprise à prospérer dans un environnement qui change sans cesse et de façon imprévisible. Quand un dirigeant parle aujourd'hui d'« entreprise agile », il est souvent difficile de savoir s'il se réfère aux quatre valeurs de 2001 ou à cette idée plus ancienne de réactivité.

Marketing, ressources humaines et management

Le marketing a été l'un des premiers métiers à se donner son propre texte. Le 11 juin 2012, un groupe de professionnels du marketing réunis à San Francisco pour une rencontre baptisée SprintZero rédigent un « manifeste du marketing agile », calqué sur celui de 2001. Ils y valorisent notamment l'apprentissage validé par des mesures plus que les opinions et les conventions, les campagnes ajustées par étapes plus que les grandes campagnes lancées d'un seul coup, et beaucoup de petites expériences plus que quelques gros paris. La parenté avec le logiciel est réelle : une campagne en ligne se mesure et se corrige en quelques jours.

Le mouvement gagne ensuite les directions générales. En mai 2016, la Harvard Business Review publie « Embracing Agile », signé par Darrell Rigby, Jeff Sutherland (cocréateur de Scrum et signataire du Manifeste) et Hirotaka Takeuchi. Les auteurs y défendent l'extension des méthodes agiles au-delà de l'informatique, en précisant qu'elles conviennent surtout aux problèmes complexes dont la solution n'est pas connue d'avance, et beaucoup moins aux activités routinières.

Deux ans plus tard, dans la même revue, Peter Cappelli et Anna Tavis décrivent l'arrivée de ces idées dans les ressources humaines sous le titre « HR Goes Agile ». La première pratique abandonnée est souvent l'entretien annuel d'évaluation, remplacé par des retours plus fréquents, mieux accordés à un travail organisé en projets courts. Les deux auteurs parlent eux-mêmes d'une agilité « allégée » : les entreprises retiennent les principes généraux sans reprendre tous les protocoles du monde logiciel.

Plus on s'éloigne de l'équipe qui produit quelque chose, plus le sens du mot se dilue. Remplacer un entretien annuel par des retours mensuels est un changement précis. Annoncer qu'une entreprise de vingt mille salariés « devient agile » ne désigne aucune pratique en particulier.

Dans l'administration

Plusieurs États ont repris ces méthodes pour leurs services en ligne, c'est-à-dire pour du logiciel, mais dans des organisations qui n'en avaient pas l'habitude. Au Royaume-Uni, le Government Digital Service est créé en avril 2011. Son manuel demande aux équipes qui construisent un service public numérique de travailler de façon agile, en quatre phases : comprendre les besoins des usagers, essayer des prototypes, construire le service réel, puis le mettre en service définitif quand les retours des usagers montrent qu'il répond à leurs besoins.

En France, la première « startup d'État » est lancée en 2013 pour refondre le portail data.gouv.fr, dont la nouvelle version ouvre en décembre de la même année. La formule confie un problème précis à une petite équipe autonome, réunie autour d'un agent public qui porte le projet. Le programme beta.gouv.fr l'a étendue depuis à plusieurs dizaines de services. Ces exemples montrent qu'une administration peut travailler par petites livraisons. Ils ne disent pas ce que deviennent ces équipes quand elles doivent s'insérer dans les procédures budgétaires ordinaires.

À la maison

L'essayiste américain Bruce Feiler a popularisé l'idée d'une agilité familiale dans une conférence TED de 2013, consacrée à la « programmation agile » appliquée à la famille, et dans son livre The Secrets of Happy Families, paru la même année. Il y raconte comment une famille dont le père est développeur a adopté une réunion hebdomadaire et des listes de tâches matinales, puis comment il a repris ces usages chez lui. Dans le même esprit, Jim Benson et Tonianne DeMaria Barry proposent dans Personal Kanban (2011) deux règles : rendre son travail visible et limiter le travail en cours, c'est-à-dire le nombre de choses commencées et non terminées.

La réunion du dimanche applique à une famille ce que le douzième principe du Manifeste demande à une équipe :

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

Principes sous-jacents au Manifeste agile (2001), texte intégral

Feiler rapporte des témoignages et sa propre expérience, qui n'ont pas la valeur d'une étude.

Ce qui se transpose et ce qui résiste

Ce qui se transpose le mieux est donc la boucle courte : produire quelque chose d'utilisable, le montrer et corriger d'après les réactions. Cette boucle vaut pour tout travail dont on ne sait pas d'avance exactement ce qu'il doit produire.

Ce qui se transpose le moins bien tient à une propriété particulière du logiciel, qui est de se modifier à faible coût. Une équipe de développement peut livrer une version imparfaite le lundi et la corriger le jeudi, surtout si elle dispose de tests automatisés qui vérifient en quelques minutes que rien n'est cassé (voir Les pratiques d'ingénierie). Un chirurgien n'a pas cette possibilité avec son patient, ni un maçon avec une dalle de béton. Dans ces métiers, la boucle courte s'applique à la préparation et aux maquettes, tandis que l'exécution relève de procédures stables. L'article du corpus Modèles mentaux sur les décisions réversibles et irréversibles développe cette distinction.

Limites et pièges

Le mot employé comme synonyme de flexibilité. Dans le discours des entreprises, « agile » signifie souvent que les salariés devront s'adapter à des réorganisations fréquentes ou faire autant avec moins de moyens. Rien dans le Manifeste ne va dans ce sens. Son huitième principe demande au contraire un rythme que chacun puisse tenir indéfiniment (voir Le rythme soutenable).

Les rituels sans le mécanisme. Une réunion debout où chacun rend compte à son chef est une réunion de contrôle, quel que soit son nom. Le signe le plus sûr est l'absence de livraison : si rien d'utilisable n'est montré à un bénéficiaire à la fin du cycle, il manque l'essentiel.

Des preuves presque absentes. Les preuves sont déjà modestes pour le logiciel, comme le montre l'article Que valent les preuves ?. Hors du logiciel, elles se réduisent à des témoignages et à quelques enquêtes déclaratives. On peut essayer ces méthodes à petite échelle et observer ce qui change, sans affirmer qu'elles ont fait leurs preuves.