(Initialement publié sur LinkedIn le 14 février 2019 : https://www.linkedin.com/pulse/les-points-sur-le-i-dagile-%C3%A9pisode-1-origines-christophe-keromen/)
Dans la communication sur l’agilité, deux zones de floues me paraissent dommageables :
- Non, l’agilité n’est pas née avec le manifeste agile, c’est l’objet d’un premier article
- Non, l’agilité ne s’obtient pas via des « méthodes », c’est ce que nous allons explorer ici.
J’ai sué sur cet article pour tenter de le rendre compréhensible, mais j’ai conscience de sa longueur et de son aspect sinueux ! Si le détail de cette réflexion vous ennuie, je vous propose directement de commencer la conclusion : Que fait-on de tout ça ?
Que fait-on de tout ça ?
Qu’est-ce que ça peut faire que l’on ait parlé d’agilité avant le manifeste agile de 2001 ? C’est bien dans l’IT que l’agilité est devenue populaire, non ?
Partir de l’Agile-IT, celle centrée sur le manifeste agile de 2001, pour aller vers l’entreprise agile génère deux inconvénients :
- celui de la légitimité : en quoi venir de l’IT rend crédible pour parler à l’entreprise entière ? En quoi est-ce même une bonne idée ?
- cette Agile-IT a émergé autour d’équipe de taille réduite (moins de 10 personnes !), passer à l’entreprise implique donc une mise de l’agilité à l’échelle, créant artificiellement un nouveau problème. Ce qui convient bien à certains fournisseurs 🙂 (cf. la dénonciation par Martin Fowler de « l’Agile Industrial Complex »).
Je propose de considérer que l’Agile-IT, centrée sur le manifeste agile, s’inscrit dans un mouvement plus ample qui s’interrogeait déjà dans les années 90 sur l’agilité d’entreprise. Et que dans un mouvement en spirale, nous nous retrouvons de nouveau à interroger l’agilité d’entreprise, en y ajoutant toute l’expérience et la dynamique communautaire provenant de l’Agile-IT.
Qu’est-ce que ça change qu’on parle de « méthode » ou de démarche agile » ?
Le paradigme.
L’emploi du terme « méthode agile » sous-entend qu’il suffit d’appliquer une suite d’étapes pré-définies pour apporter une solution toute faite aux problèmes complexes des entreprises.
Pour les familiers des travaux de Ralph Stacey ou David Snowden, c’est confondre domaine compliqué (où on applique des best practices) et domaine complexe (où on avance de manière empirique). Et par conséquent, c’est encourager à acheter des solutions sur étagères : Scrum, SAFe, « Modèle Spotify » revu et tarifé par les grands cabinets…Re – Martin Fowler et Agile Industrial Complex.
Comme le dit Camus :
« Mal nommer les choses, c’est ajouter au malheur du monde. »
Albert Camus
Fin de la … conclusion !
Des « méthodes projets » au « framework Produit »
Nous l’avons vu dans l’article précédent, sont apparues dans les années 90 des « méthodes légères » alternatives (lightweight methods) pour le développement logiciel.
En 2001 à Snowbird, 17 porteurs de ces méthodes ont élaboré le manifeste « agile » regroupant ces méthodes sous le label « agile ». Ce terme « agile » a été inspiré par le courant pré-existant de « l’entreprise agile », issu du manufacturing, tout comme Jeff Sutherland avait trouvé son terme « Scrum » dans un article des années 80 (!) traitant des leçons à tirer d’entreprises industrielles performantes (The New New Product Development Game de Takeuchi & Nonaka).
Le contexte du manifeste de 2001 était celui des « méthodes de gestion de projet » appliquées au développement logiciel. C’était il y a 20 ans.
Aujourd’hui, deux évolutions importantes se sont produites (entre autres) :
- la principale méthode orientée code (eXtreme Programming) a quasiment disparu : je constate dans les conférences que les jeunes générations ne connaissent même pas ce nom et ne savent pas de quoi ça parle. Plusieurs initiatives l’ont remplacée : les mouvements Software Craftsmanship, DevOps mais aussi l’immobilisme qui consiste à ne pas se préoccuper de l’ingénierie !
- l’aspect « méthode de gestion de projet », en particulier dans Scrum, a été complètement effacé au profit de l’orientation produit. En 1999, le Scrum Guide disait « Scrum is a framework for a project whose horizon is no more than one month long, where there is enough complexity that a longer horizon is too risky« . La version 2017 du guide ne mentionne plus qu’une seule fois le mot projet : « Each Sprint may be considered a project with no more than a one-month horizon. » Amusez-vous en revanche à compter le nombre de fois où le mot produit est employé 🙂
Cette transition se concrétise par exemple par des conférences du type « Culture projet vers culture produit ».
Aujourd’hui, parler de « méthode de gestion de projet » pour qualifier Scrum parait donc un contresens.
Cf. Jeff Sutherland, co-auteur de Scrum sur Quora :
It (Scrum) did not have the detailed practices in “methodologies” and was a framework for adopting additional practices that worked in various environments.
Jeff Sutherland
Confusion de niveaux
En 2001 le manifeste agile se détache des pratiques puisqu’il décrit l’agilité en se concentrant sur des « valeurs » et des principes.
On peut y voir l’origine de l’étrange opposition entre being agile et doing agile que nous, agilistes, mettons souvent en avant pour nous plaindre du contexte culturel de notre intervention : « dans cette entreprise, ils font du doing agile, mais ne sont pas agiles (being) ».
Being agile oppose un niveau logique décrit par des « valeurs » et des principes (en ignorant au passage les prémisses sous-jacents qui demeurent implicites, comme la théorie des systèmes, la théorie des contraintes, la cybernétique…) à un autre niveau logique, Doing agile, celui des pratiques (Daily Meeting, retrospective, sprint…). Opposer comme bon et mauvais, deux termes qui ne relèvent pas du même niveau logique, me parait source de confusion.
« Ce doit être being OU exclusif doing » relève d’une question de paradigme, celui du raisonnement dualiste (logique du tiers exclu). Ce qui empêche d’imaginer un monde où les deux fonctionnent ensemble. Or, comment peut-on être sans faire ? Comment savoir qu’on est, sans observer ce qu’on fait ?
Serait-ce une autre manière d’invoquer la diabolique « résistance au changement » ?
Nous faisons comme si les systèmes humains sur lesquels nous intervenons allaient sagement attendre sans réagir. Et quand ils réagissent, nous appelons ça paresseusement « résistance au changement ».
Arnaud Tonnelé
Nous, agilistes, entretenons cette confusion quand nous acceptons de dégrader une transformation agile en « déploiement Agile », ce qui se résume dans la grande majorité des cas par commencer par mettre en œuvre Scrum au niveau des équipes et SAFe au niveau des produits. Or Scrum se situe au niveau logique « package de pratiques », donc doing agile et pas au niveau logique « principes », le merveilleux being agile. Nous y reviendrons plus loin.
Un changement de paradigme systémique serait de tenter de réconcilier ces deux facettes en deux composantes d’un processus d’apprentissage basé sur les boucles de feedback.
Une autre plainte : SAFe !
Nombre d’agilistes se plaignent du framework SAFe, lorsqu’il est imposé comme la solution unique de l’agilité à l’échelle, dans des contextes d’entreprises pourtant fort différents.
Le systémicien J-A Malarewicz nous avertit gentiment :
Je me plains d’une situation à laquelle je contribue et dont je tire un bénéfice.
J-A Malarewicz
Considérons la situation sous cette angle…
Quand l’essentiel de notre boulot consiste à accompagner la mise en place de Scrum au niveau d’une équipe, peut-on se plaindre que les entreprises réclament la mise en œuvre de SAFe pour synchroniser plusieurs équipes ? SAFe est à Scrum ce que « Raichu » est à Pikachu : son évolution naturelle : https://www.pokepedia.fr/Pikachu.
A un framework d’équipe qui impose une collection de pratiques et de rôles, correspond à l’échelle un framework d’ensemble d’équipes qui impose…une collection de pratiques et de rôles ! C’est cohérent, rationnel.
En résumé, si l’on veut challenger le recours automatique à SAFe, ne devons-nous pas commencer par réfléchir au recours systématique à Scrum ?
Nous, agilistes, ne sommes nous pas en train de gagner notre vie en creusant les chausse-trappes dont nous nous plaignons in fine ?
Paradoxalement, l’agilité manque de méthode
Définition du Larousse : « Méthode : ensemble ordonné de manière logique de principes, de règles, d’étapes, qui constitue un moyen pour parvenir à un résultat. »
Le lecteur tenace qui m’aura suivi jusque-là risque de lâcher-prise en se disant : je n’y comprends plus rien, méthode ou pas méthode ?
Le terme « méthode » embarque avec lui un élément du paradigme mécaniste : la pensée newtonienne et cartésienne (« discours de la méthode »). La définition du Larousse porte en creux (« ensemble ordonné de manière logique », « étapes ») l’idée d’un processus séquentiel basé sur des jalons (« phase-gate process« ), ce que l’on nomme aussi waterfall ou cycle en cascade.
Employer le terme « méthode » risque fort de nous éloigner de l’agilité en nous ramenant dans la pensée traditionnelle.
Revenons à Scrum : il y a deux dimensions dans ce framework :
- une première dimension processus de production, pour laquelle l’appellation de framework est plus appropriée que celle de méthode;
- une seconde dimension cherchant à soutenir la transformation nécessaire vers une production plus efficiente. Ce que l’on nomme couramment « transformation agile ». Malheureusement, si Scrum définit un cadre pour la production agile, il reste très vague sur la démarche de transformation. Celle-ci ne repose que sur le rôle de Scrum Master. Dans le paragraphe « Scrum Master Service to the Organization » du Scrum Guide est vaguement évoqué « Leading and coaching the organization in its Scrum adoption« .
Deux erreur sont alors commises :
- sous-estimer cet aspect transformatif du rôle de Scrum Master. Erreur commise dans la grande majorité d’entreprises françaises utilisant Scrum, ou le prétendant, puisque du coup Scrum avec un Scrum Master au rabais est un Scrum non transformant.
- puisque le rôle transformatif n’est pas rempli par le ScrumMaster, on va faire appel à un Coach agile pour la transformation. Mais comme la plupart du temps, on va demander au coach agile de coacher…des équipes en Scrum, on tourne en rond et il ne se produit guère de transformation. Homéostasie, soupirerait un systémicien.
Le constat est identique pour SAFe qui propose une méthode de déploiement (ce qui rassure les entreprises qui se retrouvent en terrain connu), mais parle peu de la démarche de transformation culturelle nécessaire pour que le système organisé en SAFe puisse produire avec agilité.
Autrement dit, que ce soit pour Scrum ou SAFe, on vit dans l’illusion qu’en appliquant un framework pour produire de manière agile (ou qu’on le prétend), cela aura pour conséquence une transformation agile de l’entreprise.
Sortir de l’agilité « manifesto-centric »
C’est bien sur le plan de la transformation agile de l’entreprise que nous manquons de méthode pour structurer nos interventions. Ce qui se comprend puisque ce n’est pas le sujet du manifeste agile-IT, centré sur une équipe de développement de moins de 10 personnes !
“ At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.
Agile Manifesto for Software Development
Avec ça, vous vous sentez équipé pour aller transformer une entreprise ?
« Kanban » (pour l’IT) de David J. Anderson qui n’est pas centré sur le manifeste agile, mérite plus l’appellation de méthode, puisque proposant une succession d’étapes, voir par exemple Driving Evolutionary Change with the Kanban Method ou The Difference Between The Kanban Method and Scrum.
Il faut ici saluer également « Lean Change management » de Jason Little qui ne traite pas du tout de production agile, mais bien d’une démarche agile de transformation vers plus d’agilité.
Sortons enfin de l’agile-IT pour regarder ce que font les experts de la transformation comme par exemple Arnaud Tonnelé, auteur de « Réussir vos transformations« . S’il ne revendique pas l’appellation « Agilité Contrôlée » (bien au contraire !), la première partie de son bouquin est pourtant la description la plus claire et précise que j’ai lu sur ce sujet.
« La loi de Z est l’une des principales sources de perte de temps lors des transformations. Elle nous incite à passer d’une pratique très linéaire (Conception > Communication > Exécution) à des démarches itératives, faites de petits pas, de feedbacks, de boucles d’apprentissage, d’expérimentations »
Arnaud Tonnelé
Si ça ne parle pas d’agilité ! Pour savoir ce qu’est la terrible loi de Z, achetez son livre 🙂
Bon, à mon goût Arnaud mélange trop le mot « méthode » avec démarche, discipline, …mais c’est pour chipoter 🙂
Conclusion ?
se reporter au début de l’article 😉
Christophe Keromen Transformation Inspirante 
Un commentaire