Canevas de description d'une pratique

Voici les éléments qui me semblent pertinent pour décrire une pratique agile. Nous allons prendre pour exemple une pratique Scrum relativement récente, la Définition de 'fini'.

Parlons d'abord, même si ce n'est pas la première chose qu'on lira, du descriptif succint d'une pratique. (La première chose qu'on lira, c'est le nom, j'y reviens plus bas.) Le référentiel n'a pas vocation à se substituer aux livres, articles et contenus de formation qui donne une définition plus précise et plus détaillée de chaque pratique, compétence et outil abordés. Il s'agit donc ici de se borner à un paragraphe court qui reprend l'essentiel.

Un autre exercice délicat consiste à choisir un nom canonique pour cette pratique. La plupart de mes collègues francophones utilisent un demi-anglicisme, et parlent de "Definition du Done", quand ce n'est pas le terme anglais qu'ils utilisent directement. Quand c'est possible, il me semble souhaitable de vraiment traduire, c'est pourquoi j'ai préféré "fini" à "done".

Le but n'est pas de faire évoluer le lexique, même s'il est tentant de chercher jouer de son influence... Ma préférence irait au terme "Liste Sashimi", le terme "sashimi" bénéficie actuellement d'un petit effet de mode, et comme l'illustre le site Web de cette formation de mon ami et collègue J.B. Rainsberger il est parlant et plaisant. Mais cette appellation pour désigner une pratique spécifique reste tout à fait marginale.

En tout cas, pour toutes ces raisons, il me semble important de recenser les synonymes connus qui désignent la même pratique ou des pratiques tellement voisines que nous les considérerons comme une seule (par exemple le Sprint de Scrum ne diffère pas assez de l'Itération d'XP pour y voir deux pratiques distinctes).

Une pratique s'accompagne généralement d'un certain nombre d'erreurs classiques, de contre-sens et d'abus. En rencensant les plus courantes, on donne de la profondeur à la description brève (mais toujours sans chercher à se substituer à un contenu plus pédagogique), et on encourage à se méfier des imitations et contrefaçons.

Conformément à la division "principes, concepts, pratiques, compétences" j'ai choisi de faire ressortir de cette pratique le côté visible: je sais qu'une équipe utilise une pratique quand je peux le constater par des signes observables dans l'espace de travail, par exemple une feuille de paperboard sur laquelle on peut lire la (ou les) définition(s) de "fini".

(C'est un arbitrage de ma part, certaines personnes diront qu'il suffit qu'une équipe connaisse sa définition de "fini" et que tout le monde soit d'accord. Pourquoi pas: dans ce cas, le signe observable consiste à s'asseoir avec plusieurs personnes dans l'équipe et leur demander de réciter cette définition. Je suis presque certain que dans ces conditions chacun donnera une définition de "fini" légérement différente; je vous renvoie donc à la rubrique "erreurs classiques".)

Comme indiqué précédemment, une pratique ne vaut que par les bénéfices qu'elle confère au projet. Décider, en conscience, d'adopter une pratique, c'est s'engager à vérifier quelques temps après si ces bénéfices ont bien été obtenus, et remettre en question sa vision du fonctionnement du projet si ce n'est pas le cas. L'objectif n'est pas d'utiliser telle et telle pratique pour le plaisir de s'identifier comme "Agile" mais bel et bien d'obtenir ces bénéfices. Notamment, chaque pratique se caractérisera aussi par un coût d'utilisation plus ou moins grand et une efficacité plus ou moins nette: notre objectif, idéalement, est d'obtenir avec le minimum de pratiques, exigeant le minimum d'effort pour les adopter, le plus grand nombre de bénéfices possibles sur les aspects du projet qui nous intéressent. Peu importe d'où viennent ces pratiques - de Scrum, d'XP, de Lean...

Il est cependant important, pour plusieurs raisons que j'approfondira dans des billets à venir, de positionner les pratiques dans un contexte historique, de retracer leurs origines et leur évolution. La "définition de 'fini'" ne fait partie de Scrum que depuis quelques années, et son intégration définitive dans les pratiques considérées comme indispensables ne remonte qu'à 2006-2007 environ d'après mes recherches. (Perfectibles, sans doute: c'est pourquoi je citerai mes sources.) Ou bien il est possible de pratiquer Scrum sans utiliser une définition explicite de "fini" - auquel cas on doit se demander s'il est nécessaire dans un contexte particulier d'utiliser cette pratique - ou bien cet évolution s'explique par le fait que seules les équipes qui l'utilisaient réussissaient dans leur application de Scrum, et qu'on a finalement mis le discours en conformité avec la pratique. La différence entre ces deux scénarios n'est pas anodine.

Un dernier élément, mais qui a son importance, consiste à relever les travaux scientifiques pertinents. Ceux-ci sont de deux types: théoriques ou conceptuels, qui vont donner un éclairage plus précis et plus rigoureux sur les mécanismes par lesquels une pratique produit ses effets; et, les plus importants, empiriques, qui vont constater dans des conditions contrôlées la réalité et l'importance quantitative de ces prétendus effets.

Cette validation scientifique n'est pas un prérequis à l'utilisation de pratiques qui ont montré leur efficacité. J'aurai l'occasion de revenir sur ce sujet, mais il faut bien constater que le dialogue entre les chercheurs qui s'intéressent à la dynamique des projets agiles d'une part, et les praticiens d'autre part, n'est pas encore d'une grande qualité. On ne s'étonnera pas, par conséquent, que la recherche tarde à s'intéresser à ce que les praticiens trouvent évident depuis longtemps, ou que ces derniers ignorent des résultats que les chercheurs considèrent comme acquis. Mais la convergence au fil du temps entre
ces deux communautés me semble indispensable.

Si les pratiques sont réellement utiles et produisent leurs effets de façon fiable, alors on doit être en mesure de le prouver; sinon c'est qu'elles ne sont qu'un placebo, et leur utilisation est nuisible puisqu'elles mobilisent une partie de l'énergie des intervenants d'un projet, qu'ils pourraient consacrer à d'autres pratiques qui elles sont réellement utiles.