C’est incroyable la quantité d’articles que j’ai lus ces derniers temps, ou le nombre de personnes que j’ai entendues discuter de la même chose : la fin de l’Agile.

Foutaises.

Honnêtement, quand je les entends, j’ai l’impression que ces personnes pourraient tout aussi bien être des prédicateurs affirmant que puisque le calendrier maya se termine, le monde se termine. Vous savez quoi ? Il ne s’est pas terminé.

Ce qui devrait prendre fin, en revanche, c’est la mauvaise interprétation de l’Agile par ces personnes.

Il y a quelques mois, j’ai écrit que je n’avais jamais lu le Manifeste Agile, et que je ne le lirais probablement jamais.

“Seuls les imbéciles ne changent jamais d’avis” : je l’ai lu.

Et je suis heureux de l’avoir fait. Et j’ai aussi lu les 12 principes derrière le manifeste. Saviez-vous que c’étaient deux choses séparées, même si naturellement liées ?

Mais commençons par le commencement, et regardons le manifeste lui-même :

Nous découvrons comment mieux développer

des logiciels par la pratique et en aidant les autres à le faire.

Grâce à ce travail, nous avons appris à valoriser :

Les individus et leurs interactions plutôt que les processus et les outils
Un logiciel fonctionnel plutôt qu'une documentation exhaustive
La collaboration avec les clients plutôt que la négociation contractuelle
L'adaptation au changement plutôt que le suivi d'un plan
Même si les éléments à droite ont de la valeur,
nous reconnaissons davantage de valeur aux éléments à gauche.

© 2001, Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas - cette déclaration peut être librement copiée sous n’importe quelle forme, mais seulement dans son intégralité, y compris cette notice.

Quelqu’un peut-il me dire ce qui est mort, ou même sur le point de mourir, dans les éléments à droite ?

• Les processus et outils ont-ils plus de valeur que les individus et leurs interactions ?
• Une documentation exhaustive a-t-elle plus de valeur qu’un logiciel fonctionnel ?
• La négociation contractuelle a-t-elle plus de valeur que la collaboration avec les clients ?
• Le suivi d’un plan a-t-il plus de valeur que l’adaptation au changement ?

Si quelqu’un peut répondre honnêtement oui à l’une de ces questions, je serais heureux d’entendre des expériences et des preuves concrètes.

Vous avez remarqué que j’ai aussi copié la “notice” du manifeste ? Elle dit que l’intégralité du texte doit être copiée. Et il y a une bonne raison à cela. Vous ne pouvez pas prendre seulement une partie du manifeste et prétendre être agile.

Le contexte, c’est tout

Regardons la première phrase :

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.

Tellement de choses là-dedans, qui ont été largement obscurcies. Je pourrais développer le mot “découvrons”, qui présente évidemment le manifeste agile comme non-déterministe. Mais le plus important ici, c’est “développer des logiciels”.

Oui, “Agile” est une mode. Et non, ça ne signifie pas que vous devriez l’utiliser pour n’importe quel objectif pour lequel il n’était pas destiné. La plupart du temps, ça n’a même pas de sens !

Non, ce n’est pas fait pour les industries du hardware.

Non, ce n’est pas fait pour gérer des pipelines commerciaux.

Non, ce n’est pas fait pour la gestion de projets marketing.

Tous ces domaines ont leur environnement spécifique, leurs contraintes, leurs exigences, et l’agile n’est pas fait pour eux. C’est très bien si vous pouvez quand même en tirer des leçons applicables. Mais ne blâmez pas l’agile quand il ne vous aide pas à faire ce pour quoi il n’était pas conçu.

Surtout, ce n’est pas une méthode.

L’Agile est un paradigme. Pas une méthodologie. Pas une méthode.

La première énorme erreur, bien que la plus courante, est de croire que l’Agile est une méthodologie ou une méthode.

Faisons un peu de vocabulaire, et appelons notre vieil ami Wikipedia pour ça. Pas le plus fiable, mais il contient un “savoir populaire” qui ne doit pas être sous-estimé.

Méthodologie : La méthodologie est l’analyse systématique et théorique des méthodes appliquées à un domaine d’étude. Elle comprend l’analyse théorique du corpus de méthodes et de principes associés à une branche du savoir. En général, elle englobe des concepts tels que le paradigme, le modèle théorique, les phases et les techniques quantitatives ou qualitatives. […] Méthodologie et méthode ne sont pas interchangeables. Ces dernières années, cependant, il y a eu tendance à utiliser “méthodologie” comme un “substitut prétentieux au mot méthode”. Utiliser méthodologie comme synonyme de méthode ou ensemble de méthodes conduit à de la confusion et des mauvaises interprétations.

Méthode : La méthode scientifique est un ensemble de techniques d’investigation des phénomènes, d’acquisition de nouvelles connaissances, ou de collecte et d’intégration de connaissances antérieures. Pour être qualifiée de scientifique, une méthode d’investigation est généralement basée sur des preuves empiriques ou mesurables soumises à des principes spécifiques de raisonnement.

Paradigme : En science et en philosophie, un paradigme est un ensemble distinct de concepts ou de schémas de pensée, comprenant des théories, des méthodes de recherche, des postulats et des normes de ce qui constitue des contributions légitimes à un domaine.

Donc, là où la méthodologie pourrait normalement définir l’Agile, la tendance à confondre méthodologie et méthode me conduit à recommander de préférer le mot paradigme. Dans la définition ci-dessus, il correspond parfaitement au Manifeste Agile.

En résumé :

1. Arrêtez de confondre Agile avec Scrum/Kanban/quelle que soit la méthode que vous utilisez !
2. Ce n’est pas parce que vous échouez à implémenter une méthode que le paradigme est mauvais !

L’Agile est un adjectif

Mon monde s’est effondré le jour où j’ai lu le titre d’un article de blog écrit par l’un des pères fondateurs de l’Agile : Agile is Dead (long Live Agility) par Dave Thomas (@pragdave).

Puis j’ai lu l’article en entier.

Comme je l’ai écrit précédemment, je suis d’accord avec Dave que le mot agile a été largement mal utilisé. Mais je ne crois pas que changer ce mot pour autre chose, même si ça ressemble davantage à un adjectif, puisse faire du bien. Ce n’est pas parce que la majorité des gens ont tort que ça les rend raison.

Vous savez quoi ? Essayez ceci : oubliez les définitions du mot “agile” que vous avez entendues dans les environnements business, revenez à la source, au tout premier sens.

Travailler avec l’Agile, c’est être agile.

Donc, comme le recommande l’un des 12 principes, vous ne devriez pas seulement faire de courtes itérations sur les cycles de développement, mais surtout sur la façon dont vous gérez/pilotez/traitez les choses. Là où Scrum, Kanban, l’Extreme Programming sont des frameworks, vous devriez vous en extraire régulièrement et vous demander : mon implémentation actuelle de ce framework m’aide-t-elle vraiment à être agile ? Comment puis-je être plus agile et respecter tous ces grands principes qui façonnent ce paradigme ?

Les plus grandes forces d’une méthode agile sont l’introspection et la volonté de s’améliorer.

Comment l’“Agile” peut-il mourir, dans ce contexte et avec ces valeurs ?

Ce premier article explique comment j’aimerais être agile, et le bien que je crois qu’il peut apporter. Dans les articles à venir, j’examinerai plus en détail les 4 valeurs et les 12 principes, et je partagerai mon expérience à ce sujet.

Car non, je ne crois pas que je sois réellement agile encore. C’est un long chemin et un combat permanent.

Prochains chapitres :

• Partie 2 : Individus et interactions
• Partie 3 : Logiciel fonctionnel
• Partie 4 : Collaboration avec les clients
• Partie 5 : Adaptation au changement

Image de une par joannegirardo