Approches Agiles: entre essor et récupération

Il y a quelques années, ce qu'on appelait encore "les méthodes agiles" provoquaient surtout méfiance et dérision. En 2011, le discours s'est nettement banalisé, et le danger qui apparait désormais est celui de la dilution et de la récupération commerciale. Analysons le phénomène.

Les approches dites agiles sont nées à mi-chemin des années 1990, au moment ou battait son plein la "bulle spéculative" concernant les entreprises spécialisées dans les technologies Internet. On parle à l'époque d'Extreme Programming et de Scrum: ce n'est qu'à partir de 2001 que ces noms barbares feront la place à un adjectif plus consensuel, "agile", choisi à l'occasion d'un petit séminaire entre spécialistes du sujet dont on pourrait s'étonner qu'il fasse encore autant couler d'encre dix ans plus tard.

Les approches agiles encore mal comprises

Étonnant - pour deux raisons. Pour le sceptique, il peut sembler inattendu que ces discours, qui étaient à l'époque considérés comme une simple mode, destinée à disparaître sans laisser de trace, persistent encore et semblent même devoir s'imposer y compris au sein de grandes entreprises françaises qu'on ne saurait taxer de fantaisie: tel opérateur téléphonique national ou telle compagnie pétrolière...

Mais pour ceux qui ont goûté à ces "bonnes pratiques", ce qui est étonnant c'est au contraire qu'elles soient encore à ce point mal comprises et mal appliquées. Une tribune récente parue dans ces colonnes, intitulée "Méthodes agiles : les écueils à éviter" est représentative de ces incompréhensions. Il m'a semblé important de rectifier les plus importantes.

La communauté agile doit admettre et accueillir la critique. (Ce terme de "communauté" est d'ailleurs significatif, il témoigne de la jeunesse d'un courant de pensée qui ne s'est pas encore pleinement constitué en discipline.) Elle a, sans doute pour marquer sa rupture avec ce qui précède, inventé tout un jargon - scrum, standup, backlog; TDD, BDD ou ATDD; timebox, itération ou mock objects. Ses évangélistes n'ont pas toujours consenti l'effort nécessaire pour être accessible à des non-initiés.

La diffusion de ces connaissances s'est reposée principalement sur des conférences: chez nous, par exemple, Agile France, Agile Tour ou encore Agile Open. Ces conférences ont longtemps été le moyen privilégié de découvrir, au-delà des clichés, la réalité de ces pratiques; elles étaient le point de ralliement de ceux qui en avaient fait un apprentissage sincère. On peut regretter cette domination de l'oral sur l'écrit, plus formel et plus susceptible d'un passage à l'échelle, mais elle est un fait.

Or, pour des raisons qui leur appartiennent, la plupart des grandes SSII françaises marquent surtout ces conférences par... leur absence.

Critiquer ou récupérer?

Toutes les critiques du discours Agile ne se valent donc pas: avant de parler des "écueils" ou de proposer une critique, encore faut-il avoir acquis une connaissance suffisante du sujet; l'expérience de terrain étant sans doute la meilleure manière de le découvrir, mais pas la seule.

Ainsi le propos consistant à énoncer que "les méthodes agiles se cantonnent au développement et au test" n'est pas seulement erroné, c'est un contre-sens. Un contre-sens qui rassure, parce qu'il suppose que ces approches ne changent, dans le fond, pas grand-chose! (Oui, s'agit-il de suggérer à des clients potentiels, vous avez raison de vous intéresser à ces pratiques; mais assurez-vous quand même de bien les entourer du carcan classique que peut apporter notre bon vieux cycle en V, que nous appliquons depuis longtemps.)

Certes, en 2001 le périmètre visé par Scrum et XP était celui des équipes de développement. Depuis il a coulé beaucoup d'eau sous les ponts; il s'est tenu bien des conférences et écrit bien des livres, et sous la bannière Agile sont venu fleurir des outils et des approches complémentaires du pur développement en mode projet.

Citons par exemple les Persona, qui permettent d'intégrer l'ergonomie au sein des projets agiles. La planification en Kanban, utile lorsque la date de fin a moins d'importance que la réactivité à la demande, par exemple chez les éditeurs ou encore pour les activités de maintenance. Des outils hérités de la mouvance Lean, qui favorisent la communication avec d'autres métiers. Ou encore l'approche Devops, qui a créé des passerelles vers les intervenants de la "prod", de l'exploitation des applicatifs.

L'approche agile en 2011 ne se résume plus à une douzaine de pratiques. Mais l'incompréhension va au-delà.

Une question de valeurs

Le périmètre visé par le discours Agile est bien, en 2011, celui de l'ensemble des activités concourant à la réalisation dans les délais d'un logiciel fiable, efficace et qui répond au besoin de ses utilisateurs. Au-delà d'une simple collection de pratiques ou de tactiques, il s'agit de repenser la façon même dont on aborde les projets informatiques, et c'est pour cela que les "agilistes" insistent tant sur la notion de "valeurs".

Parmi les risques énumérés, censément liés à l'approche agile - "le nez dans le guidon", "le projet allongé", "l'humain au coeur du système" - un seul représente véritablement un enjeu économique: celui d'un projet plus long. Or c'est déjà le résultat qu'on constate depuis des décennies, et ce quelle que soit la "méthodologie" employée.

Pourquoi? Parce que le discours sur les "méthodologies" pour mener les projets informatiques s'est délibérément cantonné à certains aspects: ceux susceptibles d'être formalisés, quantifiés et contrôlés - à l'instar du "management scientifique" de Taylor. C'est cette importance donnée au contrôle qu'on perçoit en filigrane de l'accusation d'un "pilotage le nez dans le guidon".

Le discours Agile n'est pas une "méthodologie". Pour emprunter une métaphore à Paul Graham, une "méthodologie" est comparable au cahier de procédures d'un restaurant McDonald's: c'est un programme qu'on peut transposer d'un endroit à un autre et qui fonctionnera quels que soient les personnes qui le mettent en oeuvre. On n'a pas à se soucier des individus!

Là où le bât blesse, c'est que ce qui vaut pour les hamburgers ne vaut pas pour le logiciel. L'approche méthodologique traditionnelle cherche à tout contrôler et se méfie de la créativité des individus, l'approche Agile favorise au contraire le "lâcher prise" afin de mieux exploiter les talents de chacun, quel que soit leur rôle: développeurs, experts métiers, architectes, testeurs, analystes...

Une nouvelle culture du management

On voit bien, en lisant entre les lignes des critiques formulées, que c'est cette rupture culturelle favorisant le "lâcher prise" plutôt que le controle (voire le flicage) qui pose encore question. Ainsi présenter comme un "risque" le fait que le discours Agile mette "l'humain au centre du système" peut être lu avec une certaine ironie; tout comme leur reprocher "un souci élevé sur la qualité", ou la demande d'un mode de travail qui permette "d'identifier les maillons faibles sur le projet".

Plutôt que perdre du temps à traquer les "maillons faibles", l'approche Agile consiste à s'appuyer sur les compétences disponibles et les développer. Paradoxalement, pourtant, l'exigence de visibilité et la communication permanente au sein d'un projet agile correctement mené rendent les faiblesses évidentes, par opposition à une organisation plus classique où on peut se retrancher derrière son rôle attribué.

C'est à l'équipe qu'il incombe de déterminer le moyen de progresser: formation, changement de responsabilités, et si nécessaire exclure ceux qui ne sont pas à leur place. Le manager n'est plus là pour "trancher", mais pour soutenir, vis-à-vis de "l'extérieur", c'est à dire de la hiérarchie et du reste de l'entreprise, les décisions qui permettent à l'équipe d'obtenir les meilleurs résultats.

La tentation Canada Dry

De plus en plus d'entreprises utilisatrices, qu'elles soient startup ou grands groupes, éditeurs ou industriels, obtiennent des résultats prometteurs, au prix d'une remise en question de leur culture du management. Ces succès imposent désormais aux sociétés de service de s'y intéresser à leur tour, même si leur propre culture n'est que peu compatible avec celle du "lâcher prise".

La tentation est alors très grande de se rabattre sur un ersatz: proposer quelque chose qui aura le goût de l'Agile, les bulles de l'Agile, mais... ne pourra en aucun cas apporter les mêmes bénéfices que ceux engrangés en choisissant l'article d'origine! Tout en me réjouissant de constater cet intérêt des SSII pour le sujet, je m'inquiète des contre-sens constatés.

Sans doute faut-il, comme pour tout "produit" qui serait menacé d'imitations ou de succédanés, mieux informer le "consommateur", en l'espèce les entreprises tentées par les approches agiles. Sans doute la communauté a-t-elle, par naïveté, laissé penser qu'il suffisait de reproduire mécaniquement les manifestations les plus visibles de l'agilité - les Post-It sur les murs, les réunions debout - une erreur de raisonnement classique connue sous le nom de "Cargo Cult".

Le discours Agile doit, certes, entrer dans une nouvelle phase de formalisation et de pédagogie, de démonstration plus empirique et plus rationnelle des bénéfices supposés. Mais une telle information saurait difficilement venir de sociétés de service qui n'ont, en tout cas pour l'instant, goûté aux pratiques agiles que du bout des lèvres et sans procéder à l'aggiornamento culturel qu'elles exigent.

Autour du même sujet