« ImposerAgile » : différence entre les versions

Selon l'actuel conseil d'administration de l'Agile Alliance, les méthodes Agile [https://www.infoq.com/articles/agile-alliance-survey-2006/ ont "franchi le gouffre"], 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.<br/>

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 [https://www.martinfowler.com/articles/xpVariation.html écrit à ce sujet (en)] sur XP il y a plusieurs années). À ce stade, une équipe se trouve dans la phase Shu de [https://www.martinfowler.com/bliki/ShuHaRi.html ShuHaRi (en)] et doit donc suivre les pratiques de manière assez servile jusqu'à ce qu'elle comprenne comment elles fonctionnent. Dans cette situation, le dogmatisme et l'inflexibilité sont un outil d'apprentissage (temporaire).

 

Une autre situation dans laquelle nous nous trouvons habituellement chez ThoughtWorks est celle 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 le personnel du client afin d'assurer un bon transfert et pour que les personnes du client puissent 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 ligne délicate entre une adaptation raisonnable et l'abandon des pratiques qui font notre succès.

 

Ce genre de situation montre que l'imposition n'est pas aussi claire qu'elle peut paraître, mais le point fondamental reste le suivant : l'imposition de méthodes Agile introduit 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é vers les objets 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'AgilitéRigoureuse. 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 utile à ce sujet sur la liste de diffusion XP ; en particulier, il vaut la peine de lire la réponse de Kent qui fait avancer la conversation dans une direction intéressante).