ImposerAgile
Auteur : Martin Fowler
Source : AgileImposition
Date : 02/10/2006
Traducteur : Fabrice Aimetti
Date : 16/02/2021
Traduction :
Selon l'actuel conseil d'administration de l'Agile Alliance, les méthodes Agile ont "franchi le gouffre" (en), ce qui signifie, je pense, qu'elles se répandent de plus en plus. Si cela a ses avantages, cela pose aussi des problèmes. Lorsqu'une méthodologie ou une approche de conception devient à la mode, nous voyons beaucoup de gens l'utiliser ou l'enseigner, ils se concentrent sur la mode plutôt que sur les véritables particularités. Cela peut entraîner des témoignages sur des choses faites au nom de l'agilité qui sont à l'opposé des principes des fondateurs du mouvement.
En parcourant le web, j'ai entendu quelques commentaires sur les méthodes Agile imposées à une équipe de développement par la haute direction. Imposer un processus à une équipe est totalement contraire aux principes du logiciel Agile, et ce depuis sa création.
Pour moi, l'une des principales caractéristiques des méthodes Agile est qu'elles sont CentréesSurLesPersonnes (en). Elles reconnaissent que les personnes et leur façon de travailler ensemble sont le facteur principal dans le développement de logiciels, et que les processus sont un facteur secondaire. Cela se reflète dans la première valeur du Manifeste Agile "Les individus et les interactions plus que les processus et les outils" et est renforcé par deux principes (fr) du manifeste :
- Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
- Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
Une conséquence importante de ces valeurs et principes est qu'une équipe doit choisir son propre processus... un processus qui convienne aux personnes et au contexte dans lequel elles travaillent. Imposer un processus Agile de l'extérieur prive l'équipe de l'autodétermination qui est au coeur de la pensée Agile.
Cette notion va plus loin avec un autre principe du manifeste : "À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.". Une équipe ne doit pas seulement choisir son propre processus, elle doit aussi contrôler la façon dont ce processus évolue.
Cette notion de processus adapté à l'équipe (et non l'inverse) est une condition nécessaire aux méthodes agiles, mais elle n'est clairement pas suffisante. Une équipe peut choisir un processus totalement en cascade et non Agile. Dans ce cas, il est clair que le processus n'est pas plus Agile que le goût des pommes ou des fraises. Mais les méthodes Agile ne sont pas les meilleures pour toutes les situations, et personnellement, je préfère qu'une équipe travaille d'une manière non Agile qu'elle a elle-même choisie plutôt que de se voir imposer mes pratiques Agile préférées.
J'espère donc avoir bien fait comprendre que l'imposition de méthodes Agile est un signal d'alarme. Mais quand j'en entends parler, je ne comprends généralement pas toute l'histoire. Il y a des situations qui peuvent sembler similaires de l'extérieur, mais qui ne sont pas vraiment identiques.
Un exemple est celui de l'apprentissage. L'introduction de méthodes Agile implique souvent l'apprentissage de tout un tas de nouvelles choses en même temps, dont beaucoup sont contre-intuitives. C'est particulièrement vrai pour l'Extreme Programming. Dans cette situation, il est très difficile d'adapter un processus tant que vous ne l'avez pas utilisé pendant un certain temps (j'ai écrit à ce sujet (en) sur XP il y a plusieurs années). À ce stade, une équipe se trouve dans la phase Shu de ShuHaRi (en) et doit donc suivre les pratiques de manière assez rigide jusqu'à ce qu'elle comprenne comment elle fonctionne. Dans cette situation, le dogmatisme et l'inflexibilité sont un outil d'apprentissage (temporaire).
Un autre exemple dans lequel nous nous trouvons habituellement chez ThoughtWorks est celui d'un projet co-sourcé avec une équipe cliente. Dans la plupart de ces situations, nous sommes responsables de la livraison du logiciel, mais nous devons travailler avec l'équipe du client afin d'assurer un bon transfert et pour que l'équipe du client puisse apprendre comment nous travaillons. Dans cette situation, nous sommes payés pour être aussi efficaces que possible, donc nous utiliserons un processus qui fonctionne pour nous. Cela ne signifie pas que nous n'adaptons pas le processus à l'environnement du client, c'est toujours nécessaire, mais il y a une frontière très mince entre une adaptation raisonnable et l'abandon des pratiques qui ont fait notre succès.
Ce genre de situations montre qu'imposer l'Agile n'est pas aussi tranché qu'il n'y paraît, néanmoins le point fondamental reste le suivant : imposer des méthodes Agile provoque un conflit avec les valeurs et les principes qui sous-tendent les méthodes Agile.
Ce genre de problème était inévitable. Je me souviens très bien d'une période où il était à la mode d'être orienté objet et où toutes sortes de choses bizarres étaient faites au nom des objets. Tout cela fait partie du processus normal d'adoption. Rien ne peut être fait pour empêcher que le nom Agile soit appliqué à des comportements très peu Agile, il n'y a pas de police Agile qui applique l'AgileAvecRigueur. Tout ce que nous pouvons faire, c'est pour ceux d'entre nous qui se soucient de continuer à essayer d'expliquer ce qu'est réellement l'Agile. Et je préfère expliquer que convaincre.
(Il y a une discussion intéressante à ce sujet sur la liste de diffusion XP ; en particulier, cela vaut le coup de lire la réponse de Kent qui fait avancer la conversation dans une direction pertinente).
