Le manifeste, version longue

C’est l’expérience du confinement qui a fait émerger une volonté commune d’agir face à l’urgence climatique et sociale. Nous luttions déjà, avec plus ou moins de succès, contre le faux-agile et il nous est apparu, avec le changement radical provoqué par le confinement, que c’était le moment de saisir cette opportunité pour se poser des questions essentielles sur le pourquoi de l’agilité.

L’invitation à faire la keynote d’Agile en ligne a été le déclic de l’agilité radicale.

Le manifeste que nous y avons présenté ne prétend pas être un nouveau manifeste. Nous souhaitons simplement revisiter le manifeste agile avec la situation que nous vivons actuellement.

Commençons par revenir à ce manifeste agile de 2001.

Manifeste agile

À l’origine, c’est un manifeste qui vise explicitement le développement de logiciel ; on le voit dans la 2e ligne :

Voir le logiciel fonctionner plus que …

L’agilité s’est diffusée en dehors du développement de logiciel, on l’utilise maintenant plus largement pour développer des produits (ou des services).

C’est pourquoi nous remplaçons logiciel par produit ou service.

Nous sommes donc dans le retour aux racines (le manifeste de 2001), tout en nous adaptant à la situation actuelle parce que l’agilité s’est élargie à d’autres domaines que le logiciel.

Nous allons maintenant discuter des 4 valeurs relatives du manifeste agile.

Les personnes et les interactions

La première strophe du manifeste agile, c’est :

les personnes et les interactions plus que les processus et les outils

Tout le monde s’accorde sur l’importance fondamentale de l’aspect humain mis en avant par le manifeste.

Cependant, on constate que la place des process est encore bien grande dans les organisations et que les outils sont souvent imposés aux personnes et contraignent leurs interactions plutôt que de les favoriser.

Soyons clairs : les outils sont indispensables, on l’a constaté avec le confinement et le télétravail qu’il a engendré. Mais l’outil n’est pas toujours convivial, au sens où le définit Illich et c’est un vrai problème pour les équipes agiles.

Si on y réfléchit, cette partie du manifeste concerne la façon de travailler en équipe. Avec qui, comment.

Le travail en équipe, c’est un sujet qui a été abondamment abordé par l’agilité depuis des années. De nombreuses propositions ont été faites pour que les personnes soient mieux prises en compte (ce ne sont pas des ressources !) et que leurs interactions soient favorisées :

• des réflexions se sont multipliées sur la notion de leadership dans une équipe agile,
• de nombreuses solutions sont venues pour faciliter les prises de décisions dans un groupe,
• la notion d’intelligence collective s’est fortement développée.

Alors juste énoncer qu’on préfère les personnes et les interactions parait un peu léger à l’aune de ces avancées. L’équipe est elle-même un système complexe.

Il existe un mot utilisé depuis longtemps, qui serait plus évocateur de la façon souhaitée de travailler en équipe : auto-organisation.

Auto-organisation

Pourquoi ne pas l’afficher clairement ?

C’est ce que nous faisons dans notre manifeste agile radical, dans lequel nous affichons fièrement :

les personnes et les interactions plus que les processus et les outils, mais l’auto-organisation des équipes encore plus que les personnes et les interactions

Cela aurait pu être aussi auto-gouvernance (terme utilisé par Frédéric Laloux dans Reinventing Organizations), mais le terme équipe auto-organisée est mentionné depuis le tout début de l’agilité.

Voir le logiciel fonctionner

Le 2e item du manifeste, c’est :

voir le logiciel fonctionner plus qu’avoir sa documentation complète

Ce deuxième point du manifeste agile est probablement celui qui est le moins bien compris. Il porte sur la façon dont l’équipe travaille, son approche, son cycle de vie. À une approche séquentielle basée sur des phases successives, il oppose l’approche itérative.

Il valorise plus un processus léger et empirique qu’un processus lourd et prédictif.

Rappelons que le manifeste agile, écrit en 2001, s’applique explicitement au développement de logiciel.

Le manifeste nous dit, pour prendre un exemple : plutôt que d’avoir des phases de spécification et de conception qui ne produisent que de la documentation, préférez des cycles itératifs, avec à la fin de chaque cycle un logiciel qui fonctionne. Ce qui sous-entend qu’on aura fait un peu de spécification, un peu de conception, un peu de codage et un peu de test dans chaque cycle.

C’est une invitation à arrêter le BDUF (Big Design Up Front) qui était la conséquence du développement en cascade (waterfall) ou du cycle en V populaire en France.

C’était radical à l’époque.

En 2020, voir le logiciel —et plus largement, le produit— fonctionner et moins se préoccuper de la documentation peut apparaitre moins radical.

Un débutant n’y verra pas forcément ce qui est pourtant au coeur de l’agilité :

les boucles de feedback

Chaque boucle produit un résultat qui permet le feedback des utilisateurs et plus largement des parties prenantes.

Voir le produit fonctionner n’est que le moyen, pas la finalité.

C’est ainsi que les parties prenantes peuvent évaluer la valeur que le produit leur apporte et proposer une évolution pour un prochain cycle afin que cette valeur soit plus grande. Cette confrontation fréquente avec les personnes concernées par ce que fait l’équipe, c’est ce qui permet de s’assurer de sa valeur sociale.

Valeur sociale

Le terme valeur sociale est défini par David Graeber dans son livre Bullshit Jobs :

prendre soin les uns des autres de sorte que chacun soit plus libre, profite de la vie, jouisse de la liberté et occupe agréablement ses loisirs

Cependant cela s’applique plus au travail que font les gens qu’au produit qu’ils réalisent.

Dans le livre L’entreprise altruiste, Isaac Getz et Laurent Marbacher donnent à la valeur sociale une place centrale. Elle vient, de façon inconditionnelle, avant la valeur économique.

C’est cette approche radicale que nous défendons :

voir le logiciel fonctionner plus qu’avoir sa documentation complète mais s’assurer de la valeur sociale du produit ou service à chaque boucle de feedback encore plus que voir le logiciel fonctionner

La collaboration avec le client

Le 3e point du manifeste agile, c’est :

la collaboration avec le client plus que la négociation du contrat

Un contrat, c’est l’idée qu’une équipe développe le produit à partir d’un document qui décrit précisément le produit attendu.
C’est un engagement qui parait raisonnable pour qui travaille dans le domaine industriel ou dans un domaine réglementé.

Des notions liées au contrat y sont familières :

• la maîtrise d’ouvrage commande ainsi la réalisation à la maîtrise d’oeuvre,
• le contrat inclut le cahier des charges, ou la spécification détaillée,
• dans le cas d’un appel d’offres, la négociation permet d’aboutir au choix du contractant qui va ensuite exécuter le contrat.

Cependant, cela ne fonctionne pas comme ça dans le domaine de la connaissance (knowledge work) :

• il est impossible de spécifier à l’avance ce que sera le produit final,
• c’est même contre-productif car cela pousse à développer des fonctionnalités qui ne seront pas utilisées,
• la séparation en deux entités (une qui écrit le contrat, l’autre qui l’exécute) entretient une défiance néfaste.

Tout cela était constaté bien avant le manifeste qui a entériné la valeur de la collaboration.

Rappelons que le manifeste se place du côté de l’équipe de développement de logiciel ; le client est considéré comme celui qui exprime le besoin.

Après 2001 un rôle a émergé et pris de l’importance avec la diffusion de Scrum, celui de Product Owner.

C’est avec ce représentant des clients et utilisateurs que s’est développée la collaboration. Initialement hors de l’équipe, on s’est vite rendu compte que, pour une véritable collaboration, il fallait qu’il en fasse pleinement partie.

Le Product Owner est dans l’équipe et collabore quotidiennement avec les membres de l’équipe. Le produit est développé par itérations successives et c’est lui qui oriente vers ce qui apporte le plus de valeur.

Business value

La notion de valeur dont la maximisation est dévolue au Product Owner est celle du business. En France, on utilise valeur métier, ce qui est déjà plus tourné vers les utilisateurs finaux.

Le Product Owner, à la demande des parties prenantes, cherche à maximiser la business value. C’est dans cet esprit qu’il définit les priorités dans le backlog.

Dans ces conditions, il est tout à fait possible que :

• la business value oriente le produit vers le bénéfice de parties prenantes (par exemple les actionnaires), au détriment de son utilité sociale et écologique,
• que les membres de l’équipe participent à un projet qui va à l’encontre de leur éthique personnelle.

Une équipe pourrait donc être considérée comme très agile avec un Product Owner super efficace alors qu’elle contribue à la destruction des ressources de la biodiversité et à l’augmentation du réchauffement climatique !

Impact sur le vivant

Le choc du confinement a permis de constater qu’un changement radical de nos façons de vivre était possible.

Par ailleurs, nous avons constaté que beaucoup d’agilistes se sentent concernés par l’urgence climatique et sociale et cherchent à donner au vivant non-humain et humain plus de place dans la société.

Le conseil de Bruno Latour[^ 1] —que nous faisons notre— c’est qu’il ne faut surtout pas revenir à la situation d’avant, celle de la production uniquement orientée business value.

C’est pourquoi nous défendons, pour les produits et services développés, une agilité radicale qui ne s’arrête pas à la collaboration avec le client pour simplement plus de business value :

la collaboration avec le client plus que la négociation du contrat, mais l’impact sur le vivant encore plus que la collaboration avec le client

S’adapter au changement

La dernière des 4 valeurs relatives du manifeste agile, c’est :

s’adapter au changement plus que suivre le plan

Lorsque le manifeste agile est publié, en 2001, le graal de la gestion de projet était de finir dans les délais, ces délais étant définis dans le plan initial.

Le manifeste ne dit pas que suivre un plan c’est mal. D’ailleurs on fait bien un plan à chaque sprint avec Scrum.
Non, ce qui pose problème, c’est essayer de suivre le plan à tout prix.

Surtout quand c’est le plan initial, un plan détaillé qui a été fait alors qu’on avait peu de connaissance de la situation et qu’il n’a pas été remis à jour alors que des changements l’ont impacté.

Aucun plan ne résiste au contact avec l’ennemi.

Donc plutôt que suivre le plan initial, il vaut mieux s’adapter au changement.

Il faut s’adapter, le mantra du néo-libéralisme

Cette idée que le développement agile, c’est fait pour s’adapter au changement cela a poussé des entreprises à essayer l’agilité.
Car elles se rendent bien compte que des changements, il y en a quand on est dans le domaine de la connaissance, volatil, incertain, complexe et ambigu.

Le problème c’est quand ça devient une injonction :

il faut s’adapter !

et ensuite un prétexte pour faire subir tous les changements possibles aux équipes agiles.

Cette approche simpliste de l’agilité comme outil d’adaptation au changement, cela conduit au faux-agile.

Car si tout change tout le temps, les équipes ne sont pas en sécurité. En particulier, la stabilité psychologique des équipes est nécessaire pour qu’elles soient en mesure de s’adapter.

La mise en avant de l’adaptation permanente au changement, c’est probablement ce qui fait que l’agilité soit perçue avec méfiance par les membres des équipes eux-mêmes, mais aussi par toutes celles et tous ceux qui ne sont pas dans des entreprises : dans ce qu’on appelle l’économie sociale et solidaire, dans les associations ou les collectifs, là où les notions de management, de profit et d’efficacité ne sont pas dans l’esprit.

D’ailleurs, la philosophe Barbara Stiegler[^ 2] soutient que la nouvelle injonction du néolibéralisme qui naît à la fin des années 30, en rupture avec le libéralisme classique et son « laisser-faire », c’est : « il faut s’adapter ».

S’adapter aux conditions du capitalisme…

L’agilité serait-elle le bras armé du management néolibéral ?

S’adapter à quoi ?

Il faut s’adapter, d’accord, mais à quoi ?

Un petit retour au manifeste nous éclaire sur l’intention de ses créateurs, avec le 2e principe :

Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

La formulation (ou la traduction) est discutable, mais l’intention est claire.

L’accueil des changements de besoins rejoint ce que nous avons évoqué dans le paragraphe précédent.

L’agilité permet de construire le bon produit en impliquant régulièrement (à chaque cycle) ses utilisateurs. Cependant, c’est l’équipe qui reste libre d’accepter telle ou telle proposition des utilisateurs.

Ce qui est toxique, c’est quand des changements sont imposés à l’équipe, en usant de pouvoir ou en prétextant l’urgence. En particulier quand ces changements portent atteinte à l’auto-organisation de l’équipe.

Devenir le changement

S’adapter aux changements, ce n’est pas les subir !
C’est pouvoir décider quels changements et quand les prendre en compte.

C’est aussi devenir la source essentielle des propositions, car qui est mieux placé que celles et ceux qui font le travail pour avoir des idées ?

On le constate avec le confinement : les équipes qui étaient déjà agiles (et donc auto-organisées) ont trouvé de nouvelles idées pour travailler ensemble à distance.

C’est pourquoi nous proposons cette évolution du manifeste :

s’adapter au changement plus que suivre le plan, mais devenir le changement (désiré) encore plus que s’adapter au changement subi.

En souhaitant bien sûr que le changement désiré se préoccupe de plus en plus de la valeur sociale et l’impact sur le vivant.

[^ 1]: Bruno Latour dont l’article Imaginer les gestes-barrières contre le retour à la production d’avant-crise est à l’origine de la rétro-confinement, qui a elle-même donné naissance à l’agilité radicale
[^ 2]: voir la note de lecture de son dernier livre dans Phrénosphère