Pourquoi les méthodes agiles ne sont plus agiles

Quand la révolution devient l’establishment

Le Manifeste Agile est né d’une rébellion. En 2001, les méthodologies lourdes dominaient le développement logiciel. Les modèles en cascade, les documents de spécification élaborés et les jalons rigides transformaient les projets en épreuves bureaucratiques. Dix-sept praticiens se sont réunis à Snowbird dans l’Utah et ont proposé quelque chose de radical: privilégier les individus aux processus, le logiciel fonctionnel à la documentation, la collaboration à la négociation et le changement au suivi d’un plan.

La rébellion a réussi. L’agile a gagné. Les enquêtes montrent systématiquement que la majorité des organisations de développement logiciel déclarent utiliser des méthodes agiles. Le vocabulaire des sprints, des standups et des backlogs a pénétré les conseils d’administration, les départements RH et les administrations publiques.

Mais le succès a engendré un problème que les auteurs originaux n’avaient pas anticipé. Le mouvement qui se définissait par l’acceptation du changement est devenu remarquablement résistant à sa propre évolution.

Comment l’agile est-il devenu rigide?

Andy Hunt, co-auteur du Manifeste Agile et de The Pragmatic Programmer, a identifié le paradoxe fondamental en 2015. Les méthodes agiles, écrivait-il, n’ont pas elles-mêmes été agiles. Les pratiques canoniques des frameworks populaires sont restées essentiellement inchangées pendant plus d’une décennie. Le mouvement s’est figé.

Ce gel s’explique par des raisons compréhensibles. Quand l’agile était nouveau, ses pratiques étaient des suggestions au sein d’un cadre philosophique. À mesure que l’adoption s’est répandue, ces suggestions se sont durcies en prescriptions. Les programmes de formation les ont codifiées. Les organismes de certification les ont intégrées dans leurs examens. Les cabinets de conseil les ont vendues sous forme de packages. Les pratiques sont devenues des produits, et les produits ont besoin de stabilité pour passer à l’échelle.

Une certification Scrum Master enseigne par exemple un ensemble spécifique d’événements, d’artefacts et de rôles. Cette spécificité rend la certification enseignable et évaluable. Elle la rend aussi fragile. Un praticien certifié apprend à quoi ressemble Scrum, mais la certification ne peut pas lui apprendre quand Scrum devrait prendre une forme différente.

Le paradoxe de la certification

Les certifications répondent à un besoin réel. Les organisations qui recrutent pour des rôles agiles veulent des preuves de compétence. Les praticiens veulent des diplômes qui signalent leur expertise. Le marché a répondu en créant des évaluations standardisées liées à des pratiques standardisées.

La conséquence imprévue est que l’écosystème de certification récompense la conformité. Réussir un examen PSM exige de connaître le Scrum Guide, pas de savoir quand s’en écarter. Cela façonne la manière dont les praticiens pensent leur travail. Le framework devient à la fois le plancher et le plafond.

À quoi ressemble vraiment l’agile en entreprise

Entrez dans une grande entreprise qui a « adopté l’agile » et on observe souvent le même schéma. Les équipes font des sprints de deux semaines. Elles tiennent des standups quotidiens de quinze minutes exactement. Elles gèrent leurs backlogs dans Jira. Elles estiment en story points. Elles font des rétrospectives un vendredi sur deux.

Prenons un scénario de transformation typique. Une société de services financiers adopte Scrum dans quarante équipes de développement. Chaque équipe suit la même cadence de sprint, utilise le même workflow Jira et applique le même modèle de Definition of Done. L’équipe de conformité réglementaire, travaillant sur un cycle d’audit de deux ans, fonctionne avec la même structure de sprint de deux semaines que l’équipe de banque mobile qui livre des fonctionnalités chaque semaine. Aucune des deux équipes n’a choisi cette cadence. Elle a été décidée pour elles lors d’un atelier de transformation dix-huit mois plus tôt.

Hunt a nommé ce schéma « flaccid agile. » Les équipes adoptent un sous-ensemble confortable de pratiques, ignorent celles qui exigent de la discipline ou de l’inconfort et se déclarent agiles. Les standups ont lieu, mais personne ne change de cap en fonction de ce qui s’y dit. Les rétrospectives ont lieu, mais les mêmes problèmes réapparaissent mois après mois.

Retrouver l’esprit d’origine

Le premier principe du manifeste stipule: « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. » Rien dans cette phrase ne mentionne les sprints, les standups ou les story points. Ce sont des choix d’implémentation, pas des valeurs.

Retrouver l’esprit original de l’agile exige de séparer les valeurs des véhicules. Les valeurs sont intemporelles: répondre au changement, collaborer étroitement, livrer fréquemment, réfléchir honnêtement. Les véhicules sont contextuels: on doit les sélectionner, les modifier et les abandonner selon qu’ils servent ou non les valeurs dans une situation donnée.

Ce que signifie l’agilité fondée sur les preuves

Hunt a proposé de baser toutes les décisions de processus sur des preuves du monde réel dans des conditions réelles. Cela semble évident jusqu’à ce qu’on réalise combien peu d’équipes le font vraiment. La plupart des décisions de processus dans les organisations agiles reposent sur ce que le framework prescrit, ce qu’un consultant a recommandé ou ce qu’une autre équipe fait.

La pratique fondée sur les preuves signifie traiter chaque pratique comme une hypothèse. « On pense que les standups quotidiens améliorent la coordination. Testons cette hypothèse par rapport à nos métriques de livraison réelles. » Une équipe qui mène cette expérience pourrait découvrir que trois standups par semaine produisent les mêmes bénéfices de coordination avec moins de fatigue due aux réunions. Une autre équipe pourrait constater que des check-ins asynchrones fonctionnent mieux pour son organisation distribuée.

La progression de l’estimation illustre bien ce principe. Une équipe novice suit le Planning Poker parce que les règles le disent. Une équipe compétente utilise l’estimation pour faire émerger les désaccords sur la portée et la complexité. Une équipe experte pourrait abandonner complètement l’estimation formelle parce que son historique de throughput fournit de meilleures prévisions que les story points. Chaque étape marque une compréhension plus profonde de la finalité réelle de l’estimation.

S’adapter localement, penser globalement

L’une des hypothèses les plus nuisibles de l’adoption agile moderne est que toutes les équipes devraient travailler de la même manière. Les programmes de transformation d’entreprise déploient généralement un framework unique dans des dizaines d’équipes, indépendamment de ce qu’elles construisent, de qui sont leurs utilisateurs ou des contraintes auxquelles elles font face.

Le manifeste original ne faisait pas cette hypothèse. « Inspecter et adapter » est par nature local. Ce qui fonctionne pour une équipe qui développe une application mobile grand public ne fonctionnera pas pour une équipe qui maintient un système de conformité réglementaire. Ce qui fonctionne pour une équipe co-localisée de six personnes ne fonctionnera pas pour une équipe distribuée de vingt.

Permettre l’adaptation locale exige de la confiance. Cela exige des managers qui croient que les équipes les plus proches du travail sont les mieux placées pour décider comment le faire. Cela exige des organisations qui valorisent les résultats plutôt que la conformité aux processus. Ce sont des changements culturels qu’aucun framework ne peut produire seul.

Le Manifeste Agile, c’était quatre valeurs et douze principes écrits sur un tableau blanc dans l’Utah. Il n’a jamais été conçu pour devenir une franchise. Le mouvement qu’il a lancé retrouvera sa voie quand les praticiens cesseront de demander « fait-on bien l’agile? » et commenceront à demander « construit-on la bonne chose, de la bonne manière, pour les gens qui en ont besoin? »