Je souhaite préciser tout d’abord que ce n’est pas dans mes habitudes de démonter un article. J’ai une approche toute scientifique de la vérité, qui n’est faite que de doute et de remises en question. Vous pouvez éplucher ce blog, et je suis à peu près sûr que vous n’y trouverez pas une critique sans que je propose une alternative.
Mais là, ça dépasse les bornes. On est habitués, sur internet, à des articles pas très bien informés, ou à des posts reprenant simplement les communiqués de presse de tel ou tel éditeur. Mais ce que j’ai lu hier sur les méthodes agiles dans cet article se doit d’être classé dans le domaine de l’ignorance quasi-totale, voire de la médisance…
There is nothing more dangerous than a little knowledge
J’aime bien ce proverbe anglais, et je trouve qu’il est très vrai : acquérir un peu de connaissance sur quelque chose qui était auparavant complètement inconnu peut donner la fausse impression d’avoir tout compris au problème. Je pense que c’est ce qui a touché l’auteur de cet article…
Entendons-nous bien : je ne prétends pas être un expert des méthodes agiles. J’ai participé en tant qu’orateur à quelques étapes de l’Agile Tour, mais mes conférences sont surtout des retours d’expérience, et je ne connais pas assez la théorie pour discuter de l’agilité de manière définitive. A l’occasion de l’Agile Tour Vannes, j’ai d’ailleurs préféré refuser l’honneur que m’avait fait l’équipe organisatrice de me proposer de participer à la table ronde du midi aux côtés de Régis Médina, Laurent Morisseau, Patrice Petit et Alexandre Boutin : je suis un vermisseau à côté de ces personnages de l’agilité.
Eux sont de vrais experts… mais ça serait limite injurieux (et une perte de temps intellectuel précieux) de convoquer de telles pointures pour expliquer tout ce qui ne va pas dans cet article.
Commençons par le titre
“Méthodes agiles : du dogme au pragmatisme” : l’avantage dans ce genre de titre est qu’on est tout de suite au courant du niveau de l’article. Visiblement, l’auteur de cet article n’est pas au courant que le pragmatisme est justement une des valeurs fondamentales de l’agilité. Aller écrire que l’agilité vient au pragmatisme… il faut que je cherche mes mots et ma comparaison pour bien faire comprendre l’absurdité d’une telle phrase. Voyons voir :
Picasso devrait faire preuve d’abstraction
ou bien peut-être :
Microsoft : un avenir dans l’édition logicielle ?
Il faut bien comprendre que l’agilité est justement l’inverse du dogmatisme. Ce ne sont pas des théories logicielles qui ont présidé à l’établissement du manifeste agile, mais la longue expérience d’une quinzaine de professionnels distillée dans des principes qui ont été démontrés comme facteurs essentiels de réussite des projets informatiques.
Comme une majorité de personnes qu’on rencontre sur l’Agile Tour, je suis personnellement venu à l’agilité par le chemin du pragmatisme. En fait, j’ai même commencé à appliquer des principes agiles avant de prendre connaissance de ce mouvement dans son ensemble, et nous sommes très nombreux à nous être reconnus dans les méthodes agiles après les avoir appliquées sans le savoir. Tous les principes du manifeste agile sont applicables sans aucun lien à une théorie quelconque.
Donc, ne serait-ce que sous-entendre que l’agilité a pu passer par une étape de dogmatisme montre une ignorance quasi-complète du domaine…
Trois lignes plus bas
Juste après le titre, on nous apprend que “les méthodes agiles ont souvent été mises en œuvre de manière dogmatique”. Affirmation gratuite et sans aucune référence, mais peut-être est-ce qu’inconsciemment, l’auteur a souhaité donné une piste pour corriger l’énormité du titre. Effectivement, le dogmatisme peut être dans l’application d’une méthode, mais certainement pas dans la méthode elle-même.
L’auteur continue en nous expliquant doctement que la réussite des projets agiles passe par le respect de certaines “précautions et compromis”. Passons sur le fait que toute personne un tant soit peu au courant des retours d’expérience sur l’agilité sait que la plupart des “compromis” sur les principes sont justement des causes d’échec des projets soit-disant menés en mode agile. C’est d’ailleurs un des principaux arguments des personnes qui rejettent l’approche agile : ériger en preuve de l’échec de la méthode des projets qui ont été menés en saupoudrant des notions d’agilité, sans comprendre le besoin d’adoption globale de la méthode.
Encore une fois, il faut trouver une comparaison pour bien faire comprendre la limite de ce genre d’approche. Imaginez par exemple qu’un tailleur se contente de découper les morceaux d’un costume et vous les livre tels quels. Appliquer certaines notions de SCRUM sans adopter la démarche dans sa totalité reviendrait au même : ça n’aurait tout simplement pas de sens. Ce qui n’empêche pas la souplesse, et les équipes ayant adopté l’agilité se sont souvent créées leur méthode propre. Mais cela passe par l’adaptation, et non l’écrémage.
Pour en revenir aux “compromis” proposés par l’auteur, prenons juste le premier, à savoir “répondre aux attentes des métiers en parlant leur langage”. Et l’auteur d’expliquer le principe des itérations courtes et son avantage. En quoi est-ce une “précaution” à prendre par rapport aux méthodes agiles ? C’est la base de SCRUM !
Et puis si, finalement : on va en traiter une autre, parce que la troisième vaut également son pesant de cacahuètes. “Adapter la méthode aux contraintes des métiers” explique que “le métier n’est pas forcément en mesure de déléguer en permanence une personne”. Encore une fois, ceci peut expliquer justement la mauvaise vision que les auteurs et témoins ont visiblement des méthodes agiles : s’ils ont participé à un projet SCRUM où le Product Owner n’était pas présent la majorité du temps, il n’est pas étonnant que le projet se soit mal passé : c’est une des principales causes d’échec de projets.
Allez, une dernière perle pour la route : “L’équipe projet doit faire preuve de souplesse dans la mise en œuvre des méthodes agiles, en s’adaptant en temps réel aux contraintes des métiers”. Tout l’inverse de l’idée de fixer la backlog de sprint… L’idée même que l’agilité pourrait porter de la rigidité sur l’adaptation aux besoins clients est absurde : les méthodes agiles sont justement nés de la constatation de l’effet tunnel induit par les méthodes traditionnelles. La réaction de mon ancien chef en lisant ceci : “Ce genre d’article est dangereux. En gros, ils prennent ce qui fait vendre (ce que le client veut) et pas ce qui pourrait faire mieux fonctionner le projet…” (note : ce commentaire éclairé vient d’un Certified Scrum Master).
Petit retour sur le dogmatisme
Nous parlions un peu plus haut des échecs de SCRUM (oui, le monde agile reconnait que ses méthodes ne sont pas parfaites – encore une preuve de non-dogmatisme, s’il fallait qu’on en rajoute) : Alexandre Boutin a une excellente présentation sur ce point, que je vous invite à voir si vous le pouvez. Suite à des retours concrets depuis plus de dix ans, Alexandre nous présente les causes d’échec les plus habituels de projets agiles. Une des principales est justement le manque de temps accordé au Product Owner. Une autre est l’application incomplète des principes agiles.
Ceci me fait revenir sur l’opposition entre le dogmatisme et le pragmatisme. D’un côté, je vois un retour informé et extrêmement fourni d’un professionnel de SCRUM. Pas de théorie dans cette présentation : juste des retours d’expérience suffisamment nombreux pour qu’on puisse en tirer des conclusions applicables. Pour moi, on est clairement dans le pragmatisme.
De l’autre côté, un article qui a la prétention d’apporter des “précautions et des compromis” à l’application d’une méthode qui s’impose de plus en plus comme un moyen de réussir les projets informatiques, et ce sans se préoccuper que ces conseils puissent être l’exact inverse de ce que propose la méthode.
Doutez, doutez, doutez…
Il est assez désolant que ce genre d’article puisse être publié sur un portail d’information à destination des professionnels de l’informatique, en particulier sans permettre de déposer des commentaires. L’auteur explique que les mots clés de l’agilité peuvent faire peur aux développeurs et aux utilisateurs : c’est sûr que si des personnes non informées passent leur temps à expliquer les limites d’une méthode qu’ils ne connaissent pas, on continuera à ramer pour en faire comprendre les apports.
Si je peux me permettre un conseil : doutez… C’est l’approche scientifique dans toute sa grandeur que de douter de tout. L’agilité m’a beaucoup apporté, mais je n’ai pas de problème à en remettre en cause certains points. De la même manière, je vous encourage à douter de mon propre point de vue exposé dans ce blog : renseignez-vous par d’autres sources, allez voir le site Agile Tour, lisez des blogs de vrais spécialistes du sujet…
Mais par pitié, si vous êtes tombés dessus, oubliez cet article “Méthodes agiles : du dogme au pragmatisme” !
