Pourquoi ce sujet. L'expression « méthode Agile » installe l'attente d'un mode d'emploi à appliquer. Le manifeste donne des valeurs et des principes ; les cadres donnent des règles de travail. Le choix dépend surtout du type de problème rencontré.
On part de ce que le mot veut dire, avant de parler d'Agile.
Une méthode définit un chemin déterminé : des étapes, un ordre, des règles et des livrables. Elle a été écrite par une personne qui connaissait déjà la bonne façon de faire, et elle vous la transmet.
Des exemples, du plus quotidien au plus formel :
Dans tous ces cas, quelqu'un peut vous dire à l'avance ce que vous ferez à l'étape 4. C'est ce qui fait la valeur d'une méthode, et c'est aussi ce qu'elle exige : que le problème soit assez stable pour qu'un chemin écrit d'avance tienne encore au moment où vous le suivez.
Une méthode répond à : « comment faut-il procéder ? »
L'Agile répond à : « comment avancer quand on ne peut pas connaître la bonne solution à l'avance ? »
Le type de problème décide du type de réponse.
Le modèle vient de Dave Snowden, chez IBM, et il a été publié avec Mary Boone dans la Harvard Business Review en 2007. Il range les situations selon une seule question : que sait-on du lien entre les causes et les effets ?
Le quadrant en haut à gauche est celui qui nous occupe. L'Agile a été construit pour le complexe, et il perd son intérêt dans les trois autres.
| Domaine | Le lien cause / effet | La logique | Exemple |
|---|---|---|---|
| Clair | évident pour tout le monde | constater → classer → appliquer | passer une paie, appliquer un barème |
| Compliqué | existe, et s'établit par l'analyse | analyser → décider → exécuter | construire un avion déjà conçu |
| Complexe | ne se voit qu'après coup | essayer → observer → apprendre → adapter | un produit dont les usages sont mal connus |
| Chaotique | pas de lien exploitable dans l'instant | agir → constater → répondre | une panne de production, une crise |
Un problème compliqué peut être extrêmement difficile. Construire un avion déjà conçu demande des milliers d'heures d'expertise, des matériaux au comportement connu, et une chaîne de production entière. Ça reste prévisible. Des personnes expertes analysent, définissent les procédures, calculent, contrôlent l'exécution.
Le compliqué est le domaine des méthodes. C'est là que les démarches qualité et les certifications donnent leurs meilleurs résultats. Le compliqué reste difficile. Sa particularité est que le chemin s'y écrit avant d'être parcouru.
Dans le complexe, on ne peut pas déterminer assez à l'avance quelle sera la bonne solution. Les interactions sont nombreuses, les usages évoluent pendant qu'on construit.
On a une intention et des hypothèses. On n'a pas le produit final.
Traiter un problème complexe comme s'il était compliqué produit un plan détaillé sur 18 mois, tenu par des gens sérieux, et faux à partir du troisième mois.
Traiter un problème compliqué comme s'il était complexe fait réinventer par l'expérimentation ce qu'une personne experte savait déjà, et coûte le temps de cette redécouverte.
Les deux erreurs coûtent, et elles se corrigent différemment. La première demande d'arrêter de planifier si loin. La seconde demande d'aller chercher quelqu'un qui sait.
Ce que l'Agile pose, et ce que Scrum ou Kanban ajoutent par-dessus.
L'Agile pose des valeurs et des principes. Traduits en gestes de travail, ça donne :
Le manifeste tient en 4 valeurs et 12 principes, sur deux pages. Il ne contient aucune étape, aucun rôle, aucun livrable, aucune durée. Le texte est présenté dans « Lire le manifeste comme un cap ».
Ce qui manque au manifeste pour être utilisable lundi matin, ce sont des règles. C'est ce que fournissent les cadres de travail.
Trois cadres circulent courramment :
Le détail des cadres se trouve dans « Scrum, puis le flux ».
« Scrum est un cadre de travail, un framework. Il n'est pas une méthode Agile. »
Les deux mots demandent des choses opposées.
Une méthode suppose qu'une part importante du comment faire se définit avant de commencer. Dans un environnement complexe, ce qu'il faut faire se découvre pendant le travail. Une méthode prescriptive fige exactement ce qui doit rester ajustable.
L'expression réduit l'Agile à ce qui se voit de l'extérieur : les cérémonies, les post-its, le vocabulaire. Ce sont les parties visibles, et ce sont les plus faciles à copier. Le mécanisme est ailleurs, dans la capacité à apprendre pendant qu'on avance.
Méthode : prescrit comment faire.
Approche agile : organise la capacité à apprendre et à s'adapter.
Culture agile : fait de cette capacité une manière habituelle de penser, de décider et de travailler.
D'où il vient : d'expériences réussies avec des démarches qualité, des procédures et des certifications. Dans le compliqué, appliquer une méthode écrite par quelqu'un de compétent est la bonne décision, et elle a produit des résultats.
Ce que ça donne ici : les rendez-vous se tiennent, le vocabulaire est en place, le tableau est rempli, et les décisions se prennent comme avant. L'organisation a copié les gestes visibles. C'est ce que le backlog appelle « Dark Agile ».
Le moment où ça cesse d'être un dispositif de projet.
Tant que ces principes s'appliquent à un projet, ils restent un dispositif : on les installe, on les retire. Quand ils deviennent la manière habituelle de fonctionner dans l'organisation, on parle de culture agile.
Concrètement, ça se voit à ces six comportements :
L'Agile est une manière d'organiser le travail quand la connaissance se construit par l'action et le retour du réel.