"Agilité radicale", ou comment prendre en compte le social et l'écologie avec l'Agilité
Magali PERVAN
Scrum Master Senior | Partner at Dimsi Consulting | Agile enthusiast | Just Agile. No hype.
L'idée d' "Agilité radicale" a été conceptualisée pour la première fois par trois experts Agiles : Jean-Pascal Boignard, Claude Aubry et Anthony Cassaigne.
Ce concept vise à recentrer l'Agilité sur ses valeurs originelles tout en l'étendant aux préoccupations actuelles afin de mieux préparer l'avenir.
Telle que définie par ses créateurs, l'"Agilité radicale" englobe trois dimensions :
La volonté de revenir aux sources de l'Agilité n'est pas nouvelle, ni unique.
Il existe plusieurs définitions de "l'essence de l'Agilité" : Modern Agile, Heart of Agile... En effet, au fil des années, parmi les équipes et les entreprises qui ont embrassé les principes agiles, beaucoup se sont égarées.
Par exemple : en se concentrant trop sur les rites et les rythmes tels que définis dans les différentes méthodologies agiles (planification du sprint, daily stand-up meeting, rétrospective), en exécutant des plans et en suivant des processus de manière rigide, en fixant des objectifs et des contrats fixes au lieu de s'adapter au changement.
L'"Agilité radicale" veut aller plus loin.
En plus d'être fidèle à l'expression originale du manifeste agile de 2001, le concept d'"Agilité radicale" s'efforce de la rendre plus explicite, plus applicable aux défis d'aujourd'hui, qui ne sont plus tout à fait les mêmes qu'il y a 20 ans.
Qu'est ce que l'"Agilité radicale" ?
Pour définir le concept d'agilité radicale, Jean-Pascal, Claude et Anthony sont revenus sur le manifeste agile original et ont étendu ses 4 propositions afin de mieux prendre en compte la situation actuelle.
Leur proposition est la suivante :
Source : "L'art de devenir une équipe agile", par Claude Aubry.
L'idée principale derrière le manifeste de l'"Agilité radicale" est de développer des produits et des services qui apportent de la valeur au client et aux utilisateurs, une valeur qui n'est pas seulement économique mais aussi sociale et écologique.
Examinons les 4 valeurs relatives du manifeste Agile et leur évolution dans le manifeste de l'"Agilité radicale" :
1. Individus et interactions (plutôt que processus et outils)
Tout le monde s'accorde sur l'importance fondamentale de l'aspect humain mis en avant par le manifeste.
Cependant, on constate que les processus jouent encore un rôle très important dans les organisations et que les outils sont souvent imposés aux personnes et contraignent leurs interactions au lieu de les encourager.
Cette partie du manifeste aborde la manière de travailler en équipe :
Comment ? Avec qui ?
L'équipe est elle-même un système complexe. Pour mieux prendre en compte les individus et leurs interactions, les réflexions se sont multipliées sur la notion de leadership dans une équipe agile, de nombreuses solutions ont émergé pour faciliter la prise de décision dans un groupe, et la notion d'intelligence collective s'est fortement développée.
Depuis longtemps, un concept est discuté, qui serait plus évocateur de la manière souhaitée de travailler en équipe : l'auto-organisation.
(Selon la définition du dictionnaire Scrum, une équipe autoorganisée est une équipe qui choisit la meilleure façon d'accomplir son travail, plutôt que d'être dirigée (micro-management) par d'autres personnes extérieures à l'équipe).
Bien entendu, nous accordons toujours plus d'importance aux personnes et aux interactions qu'aux processus et aux outils. Mais au-delà des personnes et des interactions, l'"Agilité radicale" favorise l'auto-organisation.
2. Un logiciel fonctionnel (plutôt qu'une documentation complète)
La deuxième phrase du manifeste Agile affirme que "voir le logiciel fonctionner [doit être préféré à] avoir une documentation complète".
Selon Claude, Jean-Pascal et Anthony, ce deuxième point du manifeste Agile est probablement le moins bien compris.
Il traite de la manière dont l'équipe travaille, de son approche, de son cycle de vie. Il valorise les processus légers et empiriques basés sur une approche itérative plus qu'un processus lourd et prédictif basé sur des phases successives (comme dans les modèles de la cascade ou du cycle en V).
À la fin de chaque cycle itératif, le logiciel doit fonctionner sur lui-même, ce qui permet aux utilisateurs et aux autres parties prenantes de faire part de leurs commentaires : les boucles de rétroaction.
Recommandé par LinkedIn
Cela implique également qu'il y aura des spécifications, de la conception, du codage et des tests dans chaque cycle.
Les parties prenantes peuvent ainsi évaluer la valeur que le produit leur apporte et proposer une évolution pour le cycle suivant afin que cette valeur continue de croître. En rencontrant fréquemment les personnes concernées par ce que fait l'équipe, la valeur sociale du produit ou du service, telle que définie par David Graeber dans son livre Bullshit Jobs, est assurée :
"Prendre soin les uns des autres pour que chacun soit plus libre, profite de la vie, jouisse de la liberté et ait un temps de loisir agréable".
C'est cette approche radicale que nous défendons :
Voir le logiciel fonctionner plutôt que d'avoir sa documentation complète, mais garantir la valeur sociale du produit ou du service à chaque boucle de rétroaction encore plus que de voir le logiciel fonctionner.
3. Collaboration avec le client (plus que la négociation du contrat)
Le troisième point du manifeste Agile stipule que "la collaboration avec le client [doit compter] plus que la négociation du contrat".
En effet, un contrat implique une description précise du produit attendu, y compris des spécifications, et le maître d'ouvrage ordonne la réalisation au chef de projet.
Si cela peut être raisonnable pour toute personne travaillant dans une industrie ou dans un domaine réglementé, ce type d'organisation ne fonctionne pas dans le domaine de la recherche ou de l'IT.
En effet : il est impossible de spécifier à l'avance ce que sera le produit final, définir à l'avance les spécifications du produit, 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 - l'une qui rédige le contrat, l'autre qui l'exécute - entretient une méfiance néfaste.
Dans cette optique, un nouveau poste a émergé et pris de l'importance avec la sortie de Scrum : le rôle de Product Owner, représentant les clients et les utilisateurs au sein de l'équipe de développeurs.
C'est lui qui est chargé d'orienter le produit vers ce qui apporte le plus de valeur, itération après itération.
C'est là que se pose la question de la valeur.
Dans nos sociétés occidentales, nous considérons généralement la valeur commerciale, orientée vers les utilisateurs finaux.
À première vue, cela semble assez logique : il s'agit de maximiser les avantages pour ceux qui utilisent le produit. Cependant, considérer le produit uniquement sous l'angle de sa valeur commerciale peut entraîner des biais et des effets pervers :
Mettre de côté son utilité sociale et écologique, faire travailler les membres de l'équipe impliqués dans le projet à l'encontre de leur éthique personnelle, et même contribuer à la destruction de la biodiversité et à l'accélération du changement climatique.
L'"Agilité radicale" ne s'arrête pas à la collaboration avec le client pour simplement augmenter la valeur commerciale. Au-delà de la collaboration avec le client, nous prenons en compte l'impact sur les êtres vivants.
4. S'adapter au changement (plutôt que de suivre un plan)
La dernière des quatre valeurs relatives du manifeste agile exhorte les équipes à "s'adapter au changement plus qu'à suivre le plan".
Lorsque le manifeste Agile a été publié en 2001, le graal de la gestion de projet était de terminer à temps, conformément aux délais définis dans le plan initial.
Le manifeste ne dit pas que suivre un plan est une erreur. En fait, chaque sprint suivant la méthodologie Scrum a un plan. Le problème est d'essayer de suivre le plan à tout prix. Surtout lorsque le plan original a été établi alors que l'équipe avait peu de connaissances de la situation et qu'il n'a jamais été mis à jour pour s'adapter aux changements qui l'affectent.
Ainsi, plutôt que de suivre le plan initial, il vaut mieux s'adapter au changement. Le deuxième principe du manifeste Agile nous éclaire sur l'intention de ses créateurs : "Accueillir les exigences changeantes, même à un stade avancé du développement. Les processus agiles exploitent le changement pour l'avantage concurrentiel du client".
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 (ou de refuser) une proposition des utilisateurs.
Ce qui est toxique, c'est lorsque des changements sont imposés à l'équipe, sous prétexte de pouvoir ou d'urgence. En effet, certaines entreprises ont adopté ce mantra au point d'en faire une injonction (" il faut s'adapter ") et l'utilisent comme prétexte pour faire subir aux équipes agiles tous les changements possibles.
Ce comportement peut s'avérer très néfaste pour l'équipe, surtout lorsque ces changements mettent à mal l'auto-organisation de l'équipe.
Si tout change tout le temps, les équipes ne peuvent pas être assurées ou rassurées.
"C'est pourquoi nous proposons cette évolution du manifeste : s'adapter au changement plus que suivre le plan, mais au-delà de l'adaptation au changement (subi), nous voulons devenir le changement souhaité", expliquent les trois experts.
"Et nous espérons que le changement souhaité sera de plus en plus soucieux de la valeur sociale et de l'impact sur les êtres vivants."
Dans la deuxième partie sur l'"Agilité radicale" nous explorerons plusieurs points :
To Be Continued...