Publié par

Il y a 6 ans -

Temps de lecture 9 minutes

Le MANIFESTE AGILE est l’opium du peuple…

Depuis quelque temps, je constate une prolifération d’articles à charge sur l’Agilité. On y discute de la pertinence du terme Agile, de son galvaudage et de son rôle de paravent pour couvrir des pratiques approximatives. On aime aussi s’y donner de l’importance en annonçant l’échec de l’Agilité et en se plaçant ainsi au-dessus des masses.

Parallèlement, je rencontre souvent, dans mon travail, auprès d’équipes projets et bien sûr sur le NET des personnes qui se disent Agiles parce qu’elles font un « stand-up », mais n’ont en fait jamais dépassé le stade du Manifeste.

Aujourd’hui, le MANIFESTE AGILE [1]est l’opium du peuple…

Le Manifeste Agile n’est pas une bible

Comme l’ont dit ses auteurs, le Manifeste Agile n’est qu’un instantané[2]

Il s’agit de ce qu’un groupe de personnes a identifié comme étant les meilleures pratiques pour la réussite des projets IT à une date donnée.

Pourtant, pour certains, le MANIFESTE est devenu la bible de l’Agilité. Il est gravé dans le marbre, façon 10 commandements. Il s’écrit en capitales d’imprimerie… Beaucoup s’en servent comme d’une épée de vérité et justifient la moindre de leurs actions en le citant (souvent approximativement). La plupart n’en connaissent d’ailleurs que les 4 valeurs et ont oublié les 12 principes sous-jacents. La grande masse finalement, « le peuple », pense que l’Agilité est née en 2001.

Non, nous n’assistons pas à l’échec de l’Agilité. Non le terme Agile ne pose pas de problèmes. S’il y a un problème de mise en œuvre, il est dû à une mauvaise lecture du Manifeste.

Le ScrumBut et l’AgileWashing ont déjà été dénoncés, mais trop souvent nous attribuons ces situations à un non-respect à la lettre des pratiques. À l’inverse, je pense que ce sont ces pratiques mêmes et plus particulièrement leur représentation à travers le MANIFESTE AGILE qui, en nous ôtant notre liberté de penser, nous empêchent de réussir nos projets.

Dépasser le stade du Shu

Dans les arts martiaux japonais, on parle de Shu-Ha-Ri.

Je ne suis pas le premier[3] à effectuer le parallèle entre ces trois stades dans la maîtrise des arts martiaux et l’agilité, mais je le trouve très pertinent. Aujourd’hui, n’en déplaise à certains, nous restons encore majoritairement dans le Shu, c’est-à-dire l’appropriation des fondamentaux.

Dans le passé, le Manifeste Agile a pu être utile. Par sa simplicité et sa visibilité, il a su créer l’attention. Par son rayonnement, il a permis à beaucoup d’envisager de nouvelles approches de la gestion de projet.

Aujourd’hui, le MANIFESTE AGILE s’apparente au boulet que traîne le forçat en ce qu’il nous empêche d’avancer à pleine vitesse. Il s’est érigé en barrière qui fait obstacle à notre accession au stade supérieur du Ha (casser avec la tradition) et, à plus forte raison, du Ri (transcender).

J’en veux pour exemple cette situation que vous avez sans doute vécue, quand un client vient vous voir en vous demandant :

– Mais alors, je ne peux plus faire de documentation ?

Là, le manifeste ne nous aide pas…

Beaucoup s’arrêtent à la première partie de la proposition « des logiciels opérationnels » et pensent qu’ils n’ont pas le droit de réaliser la deuxième « une documentation ». Dans ces moments, j’aimerais faire table rase du passé (j’aimerais aussi disposer d’une meilleure traduction française, sans ambiguïté [4]). Ainsi, en arrêtant de cristalliser les réflexions autour du Manifeste, nous pourrions mieux avancer et enfin progresser vers le Ri.

Abandonner l’approche « command and control »

Je me reprends donc. Si le Manifeste Agile est devenu une entrave, c’est bien parce qu’il a été déifié. Je ne remets pas en cause son contenu, mais bien cette façon de le considérer comme une checklist à appliquer sans discuter

Tout comme l’opium obscure les sens, le MANIFESTE AGILE nous aveugle. Aujourd’hui, son omniprésence est telle que dès lors que nous nous y attaquons, nous assistons à une levée de boucliers…

Si nous en sommes arrivés là, c’est que nous devons nous battre avec le conditionnement de plus de 40 ans de développement « Waterfall ».[5] C’est cette approche « command and control » de la gestion de projet qui nous a conditionnés à accepter des checklists comme des vérités absolues.

Pour réussir nos accompagnements, n’appliquons donc pas bêtement à l’agilité ces comportements « administratifs » induits par nos pratiques passées. S’ils faisaient sens autrefois, dans une approche « command and control », ils n’ont plus lieu d’être dans une approche du type « inspect and adapt ».

 

L’Agilité au-delà du Manifeste

Non, l’Agilité ne se réduit pas au Manifeste. Au risque d’enfoncer des portes ouvertes, il est de bon ton de rappeler que l’Agilité ne naît pas en 2001. Il ne s’agit pas d’une découverte que l’on aurait soudainement effectuée, mais d’un héritage de la recherche en gestion de projet. Héritage au sein duquel on pourrait sélectivement citer :

  • The Mythical Man Month (F. Brooks – 1975)
  • No Silver Bullet – Essence and Accidents of Software Engineering (F. Brooks – 1986)
  • The New New Product Development Game[6] (H. Takeuchi, I. Nonaka, Harvard Business Review – 1986)
  • La présentation de Scrum à l’OOPSLA en 1995
  • Developing Products in Half the Time (P. G. Smith, D. G. Reinerstein – 1ère Ed. 1995)
  • La première application d’XP en 1996[7] au sein du projet C3 de Chrysler

Un héritage qui ne s’arrête d’ailleurs pas en 2001, mais continue à s’enrichir avec notamment :

  • Kanban – Successful Evolutionary Change for your Technology Business (David Anderson – 2010[8]).
  • The lean startup (how today’s entrepreneurs use continuous innovation to create radically successful businesses) (Eric Ries – 2011)

Bref…

La liste est longue et montre clairement que l’Agilité a su s’inspirer d’un historique académique riche.

Quant au terme « Agile », dont nous rattachons l’utilisation à la publication du Manifeste, il apparaît en fait dès 1991 dans un rapport commandité par le gouvernement américain et intitulé 21st Century Manufacturing Enterprise Strategy[9]

Ce rapport, publié par le Iacocca Institute, analyse les difficultés de nombreuses entreprises américaines à offrir un système industriel aussi flexible que celui de leurs concurrentes japonaises.

On y retrouve, appliqué au manufacturing, un grand nombre des principes repris plus tard par le Manifeste Agile dans l’IT. Ils y sont résumés ainsi dès l’introduction du rapport :

« Le terme “Manufacturing Agile” décrit un système industriel avec une extraordinaire capacité d’adaptation aux besoins rapidement changeants du marché, un système qui peut diligemment passer d’un modèle de produit à un autre ou d’une ligne de production à une autre, idéalement en réponse immédiate à la demande du client. »[10]

Soyons agnostiques et pensons par nous-mêmes

Arrêtons donc de nous réclamer d’un MANIFESTE AGILE, comme on se réclamerait d’une religion. Apprenons à aller au-delà, à comprendre quels sont les fondements et les buts de telles ou telles pratiques. Réfléchissons à la pertinence de celles-ci dans notre contexte. Rabelais dans son Pantagruel écrivait « Science sans conscience n’est que ruine de l’âme ». Alors, éduquons notre conscience. Appliquons, adaptons, mais faisons-le en connaissance de cause.

  • Soyons fainéants et n’utilisons que les pratiques qui nous sont réellement utiles.
  • Soyons itératifs, non pas parce que c’est un des 12 principes du Manifeste, mais parce que nous comprenons le bénéfice d’un « reality check ».
  • Soyons incrémentaux, non pas parce que cela nous a été demandé, mais parce que nous réalisons que nous n’avons pas besoin de tout, tout de suite[11].
  • Communiquons, non pas pour respecter une cérémonie Agile mais parce que nous valorisons l’obtention de l’information au plus tôt.

Et surtout, ne nous interdisons pas d’emprunter une technique à d’autres domaines ou d’innover sous prétexte que cela n’est pas dans le MANIFESTE AGILE.

Devenons enfin des artisans de l’amélioration continue

Ne soyons pas des cuisiniers qui suivent une recette et apprenons à devenir des chefs étoilés, capables de mêler le sucré et le salé, d’emprunter à la physique et à la chimie pour faire de la cuisine moléculaire et ainsi de nous réinventer sans cesse pour enfin faire de l’amélioration continue.


[1] Les majuscules sont volontaires et vous me les pardonnerez, je n’ai rien contre le manifeste en lui même mais contre sa mise sur piédestal. J’oppose ainsi dans ce texte le Manifeste Agile, qui représente le texte d’origine, au MANIFESTE AGILE, qui est sa déification.

[2] Pour plus de détails, je vous recommande l’article de Ron Jeffries : Beyond Agile : New Principles

[3] Personnellement, je l’ai rencontré pour la première fois dans le livre d’Alistair Cockburn Agile Software Development : The Cooperative Game, que je vous recommande par ailleurs.

[4] L’anglais en ce sens est d’ailleurs plus efficace puisqu’il dit bien « over » et non pas « without »

[5] Et tout ça pour une erreur de lecture puisque, dès la description de ce modèle dans l’article Managing the Development of Large Software Systems paru en 1970, Winston Royce en dénonçait les limites…

[6] Qui inspirera le développement de Scrum et au sein duquel le terme Scrum apparaît d’ailleurs pour la première fois.

[7] On notera au passage que, contrairement à ce que l’on lit assez souvent en France, la publication de Scrum a précédé celle d’XP.

[8] S’appuyant par ailleurs sur les systèmes Kanban implémentés chez Toyota dès 1953 !

[9] Le nom complet du rapport est d’ailleurs : 21st Century Manufacturing Enterprise Strategy An Industry Led View of Agile Manufacturing

[10] En anglais : « The term « Agile Manufacturing » describes a manufacturing system with extraordinary capability to meet the rapidly changing needs of the marketplace, a system that can shift quickly among product models or between product lines, ideally in real-time response to customer demand. »

[11] Nous n’en aurons d’ailleurs peut-être jamais besoin, mais en application du « Requirement Uncertainty Principle » de Watts S. Humphrey, nous ne pourrons le savoir qu’après démonstration!

Publié par

Publié par Nicolas Lochet

Une expérience projets/produits de 14 ans dont plus de 3 en coaching Agile d'équipes et d'organisation. Accompagnement depuis des niveaux de direction de projet jusqu'aux niveaux exécutifs. Speaker en conférence, écrivain, blogueur, formateur et facilitateur graphique pour partager/enseigner l'être Agile. Certifié SAFe Agilist, CSP, CSPO et Management 3.0

Commentaire

2 réponses pour " Le MANIFESTE AGILE est l’opium du peuple… "

  1. Publié par , Il y a 6 ans

    Article très intéressant et je suis globalement en phase avec ce qui est écrit. Sur ma propre expérience, j’ai plutôt vue des « échecs » de la méthode agile lié au fait que les équipes étaient AVANT le Shu. Je découvre donc, que certains échouent à cause d’une application stricte mais en fait erroné du texte écrit dans le manifeste. Penser que le Manifeste Agile est une loi gravé dans le marbre est une preuve en soit de n’avoir rien compris à l’esprit de l’agilité. Le gros problème de nos jours est qu’il faut reconvertir les personnes qui viennent du Command and Control vers un « poste » dans le monde Agile. Du coup, on en fait des Product Owner, des ScrumMaster etc.. et ceux sont eux les principaux freins à l’agilité..

  2. Publié par , Il y a 6 ans

    @Olivier Thélu. Effectivement on pourrait faire une lecture à plusieurs niveaux. On peut, comme vous le dites, voir des échecs à tous les étages. Un bon exemple serait une équipe Scrum qui applique à la lettre des pratiques Scrum mais sans esprit Agile. Typiquement un stand-up où un Scrum Master / Chef de Projet (sic.) interroge son équipe en mode directif sur ce qu’elle a fait. On respecte le daily mais on en a totalement dévoyé l’esprit!
    En France, pays ayant la culture de la hiérarchie, il est très compliqué pour les anciens chefs d’adopter les postures coopératives recherchées dans une organisation d’équipe mise à plat. Lorsqu’on peut faire comprendre que l’importance n’est pas dans le nombre de personnes que l’on manage, mais dans nos compétences à faire progresser l’équipe dans son ensemble on fait déjà un grand pas en avant!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.