Dans une bonne bouteille, vous buvez l'étiquette?

Une question malicieuse pour un sujet très sérieux, puisque l'une de mes plus grandes inquiétudes est de voir notre profession se détourner d'idées qu'elles vient pourtant à peine de découvrir et qui, bien maîtrisées, lui font le plus grand bien.

Ce qui est important dans l'ensemble certes un peu hétéroclite de notions associées au terme "Agile", ce n'est évidemment pas le mot "Agile", de la même façon que ce qui nous procure du plaisir dans une bonne bouteille de vin, c'est (en principe) son contenu.

En principe? Oui, une des vertus de cette analogie, c'est de nous rappeler que trop souvent on se délecte de l'étiquette. On appelle "effet de halo" le biais cognitif qui nous fait trouver plus plaisant un produit lorsqu'on sait qu'il provient d'une "bonne" marque, alors même que si nous faisions l'essai à l'aveugle nous ne saurions pas distinguer une piquette d'un cru à la mode.

Je ne jetterai donc la pierre à personne, mais le fait est que nous courons un risque à trop parler des étiquettes: Agile, Lean, Scrum, XP... J'entends des choses parfaitement absurdes, par exemple "Lean est le successeur d'Agile".

C'est un contre-sens pour qui connaît le contenu qu'on désigne par le terme Agile: un ensemble de pratiques, certes pas toutes de la même origine, certes pas toutes aussi largement connues et pratiquées, mais dont statistiquement, en interrogeant un assez grand nombre de personnes faisant partie de la communauté depuis longtemps (cette appartenance pourrait se déterminer par un critère concret tel que la participation à des conférences), le recouvrement nous donnerait une idée assez précise.

Citons en vrac, et pour l'exercice: le développement par les tests (TDD), le refactoring, l'automatisation du build, l'intégration continue, la conception incrémentale, les User Stories, les tests de recette, les critères "Done", les Personas, le Story Mapping, le Planning Poker, les itérations timeboxées, les rétrospectives, le tableau des tâches, le libre choix des tâches, la réunion quotidienne ou "mélée", la programmation en binômes, les demandes d'aide explicites...

Parmi les "méthodes Agiles" (le mot méthode est mal choisi, mais ce sera le sujet d'un prochain billet) on peut effectivement recenser certaines dont les préconisations sont des sous-ensembles de cette longue liste: Scrum et XP notamment.

Si on se pose la question de savoir de quel mode de pensée sont issues les pratiques Agiles, alors oui, on retombe sur quelque chose qui a de nombreuses affinités avec le discours Lean. Pour autant, le recouvrement en termes de pratiques est relativement faible.

Or, soyons clair là-dessus, ce qui fait le succès ou non d'un projet, ce n'est pas le nom du discours dont on se revendique, l'attachement identitaire des membres de l'équipe: "nous sommes Agiles" ou "nous sommes Lean". Ce qui fait le succès d'un projet c'est ce que font les gens!

De ce point de vue, force est de constater que beaucoup d'équipes se proclament "Agiles" alors même qu'elles peinent à appliquer de façon compétente des pratiques aussi élémentaires que le refactoring, ou qu'elles révèlent lorsqu'on interroge les ingénieurs des contresens sur des notions de base comme la vélocité.

Une partie de ce déficit est à mettre sur le compte de la communauté Agile elle-même: il n'existe nulle part sur le Web un "Wikipedia de l'Agilité", une description systématique, détaillée, cohérente et mise à jour des pratiques désignées par le terme "Agile".

D'où le projet actuellement prioritaire de l'Institut Agile: mettre à la disposition des personnes intéressées par le sujet un "référentiel des compétences, pratiques, notions et principes" des approches Agiles. Qu'est-ce qui différentie une compétence d'une pratique, d'un principe, etc? C'est ce que j'aborderai dans le prochain billet...