Nous avons enfin mûri. Ce que nous produisons maintenant sont des cadres d’améliorations réfléchis, et non des méthodologies (même si nous continuons par habitude à utiliser ce terme). Crystal, Scrum, Kanban en sont des exemples. Chacun contient quelques règles, pas assez pour conduire un projet, mais suffisamment pour que les personnes améliorent leur situation mieux que par simple empirisme. Les vieilles méthodologies avec un grand M sont finies. Et c’est tant mieux.

Lors de la conférence Agile Roots en 2010, j’ai donné une conférence intitulée la nouvelle méthodologie n’est pas une méthodologie (regardez également la vidéo de la conférence : vidéo de la note d’ouverture d’Alistair à la conférence Agile Roots 2010 – la nouvelle méthodologie n’est pas une méthodologie.

Le sujet de cette allocution était ce nous appelons, par habitude, « méthodologies » en référence à ce qui était fait dans les années 1980 et début des années 1990. Depuis, nous avons quelque peu mûri et ce que nous avons produit à partir de 1995 n’a plus rien à voir avec l’ancienne définition de ce mot.

Scrum, ma famille Crystal et Kanban avec un K majuscule de David Anderson (par pitié, si tentant et déroutant que cela puisse paraître, ne le confondez PAS avec le kanban avec un k minuscule qui est un système de marqueur pour un système de suivi par état) ont peu de rapport avec le terme méthodologie. Ce ne sont pas des processus à proprement parler, ce sont pour la plupart des cadres d’améliorations réfléchis, ou quelque chose avec un autre nom, ou quelque chose pour laquelle nous n’avons pas encore de nom. Mais ils ne sont pas des méthodologies au sens traditionnel du terme.

Regardons ceci de plus près en 2 étapes :

  • ils ne sont pas des processus/méthodologies
  • et nous avons encore besoin de processus/méthodologies.

1. Ils ne sont pas des processus/méthodologies.

Un processus ou une méthodologie décrit les rôles, les étapes et les relations. Scrum tel qu’issu de l’ère post-certification (CSM) le fait en quelque sorte : product owner, scrum master, réunion de planification de sprint, etc. Mais il s’agit vraiment (a) d’une approximation (b) de décorum par rapport au vrai Scrum. Le vrai Scrum (imaginez un tm ici) dit simplement ceci :

  • Réunissez un groupe pluridisciplinaire de personnes suffisamment qualifiées
  • Faites leur faire une démo ou une livraison souvent mais à part ça arrêtez de les micro-manager
  • Faites les s’auto-inspecter et s’adapter quotidiennement et mensuellement
  • Dédiez une personne disposant du temps libre nécessaire pour enlever les obstacles et veiller à la qualité de l’équipe
  • Faites en sorte que le métier parle à travers une seule personne.

Ce n’est pas un processus. C’est un . C'est juste assez de mots pour que l'équipe puisse livrer et s'améliorer. Crystal est plus et moins que Scrum. Il dit :

  • Chaque projet a besoin de son/sa propre, processus/méthodologie adapté(e).
  • Nous avons appris certaines règles/théories/lois sur comment les gens travaillent bien ensemble ; alors prêtons attention à celles-là.
  • Les équipes qui réussissent, possèdent 7 propriétés, c’est donc une bonne idée de leurs prêter attention ; en voici quelques exemples : livrer souvent, réfléchir souvent, prêter attention à la qualité de la communauté et à la qualité de la communication, obtenir du retour d’informations à tous les niveaux et de n’importe quelles directions.

C’est moins que Scrum parce que les éléments de processus présents dans Scrum n’y sont pas. C’est plus que Scrum parce qu’il liste les propriétés, les lois ou la théorie sur la construction d’équipe, ce que ne fait aucun autre cadre. Kanban avec un K majuscule se situe quelque part entre Scrum et Crystal. Il ne possède aucun élément de processus défini, mais il ajoute l’idée de l’observation transverse de la file d’attente, l’idée de placer des limites fixes sur le travail en cours (TEC), et de discuter sur ce qu’il se passe lorsque les limites du TEC sont franchies ou figées. Autrement dit, c’est un déclencheur basé sur des états pour la délibération, plutôt qu’un déclencheur basé sur le temps. Tous les 3 sont vraiment géniaux – et ce ne sont pas des méthodologies ou des processus. Nous n’avons pas de mot pour eux. Pour l’instant je suggérerais :

“Cadres d’améliorations réfléchis”

2. Nous avons encore besoin de processus et de méthodologies.

Les cadres d’améliorations réfléchis sont merveilleux, mais ils n’indiquent pas à l’équipe comment travailler, et une équipe a besoin de cela. Dans A quoi un processus est-il bon ? (discussion : Re : A quoi un processus est-il bon?), j’ai découvert qu’un processus sert :

  • à travailler avec une communication réduite
  • de check-list afin que les gens n’oublient rien.

Ces deux éléments sont importants. Une méthodologie (est différente de la seule partie que représente le processus tout en la contenant à la fois) sert à définir les rôles, attributions et points d’interactions des personnes entre les attributions et les services. Comme vous pouvez le constater, des méthodologies et des processus locaux spécifiques sont encore nécessaires et le seront toujours (je décris comment appréhender ces éléments dans Décrire les méthodologies plus simplement).

Ce que je décris dans ce modeste article de blog est que le « Processus » ou la « Méthodologie » tel que nous l’avons vu ces 30 dernières années – un épais manuel listant rôles, attributions, techniques à utiliser, points d’interactions – écrit sous la forme d’un livre de règles, destiné à être utilisé sur plusieurs organisations, plusieurs projets, plusieurs pays, plusieurs cultures, est terminé.

Certaines personnes s’attendront encore à le/les trouver, et nous pouvons nous attendre à ce que ces personnes nous le/les demandent. Mais nous ne pouvons pas satisfaire ces personnes, parce que nous, l’industrie logicielle, avons réalisé majoritairement que de tels processus et méthodologies sont sévèrement sous-optimales, et nous nous refusons de plus en plus à les produire. Malheur à celui qui produira une telle chose, malheur à ceux qui les achèteront et s’attendront à les voir fonctionner.

(Et, juste pour l’anecdote, j’ai presque signé pour préparer un document sur le niveau-SHU (discussion : Re : Shu Ha ri) pour un très grand client, afin qu’il puisse déployer x000 développeurs dans x00 compagnies dans X pays pour une transition vers l’agilité en mode big-bang ! Est-ce que ce ne serait pas un test ?!!! J’espère vraiment que je vais pouvoir le faire car cela va me pousser dans mes retranchements. Je ne pense pas vraiment que le contrat sera finalisé, ou qu’ils me laisseront faire, ou qu’ils feront ce que je suis en train d’écrire :), mais il s’agit d’une super expérience intellectuelle. (postscriptum un peu plus tard : le contrat ne s’est pas finalisé : ouf ! c’était moins une).

Qu’en pensez-vous ?

Auteur : Alistair Cockburn
Source : The end of methodology
Date de parution originale : 25 Mai 2011

Traducteur : Nicolas Mereaux
Date de traduction : 24/11/2013

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.