Présentation de l’Agilité : arrêtons avec le manifeste

(article initialement publié sur #LeMinifastAgile)

Vous rappelez-vous les dissertations de philosophies en terminale ? La première étape consistait toujours à définir les termes clefs du sujet donné.

C’est une belle habitude que je m’efforce de conserver. Car très souvent, dans la multitude des termes, concepts ou mot-clefs que nous utilisons chaque jour dans le contexte professionnel, nous n’en n’avons pas nécessairement une définition claire et partagée. “Mal nommer les concepts c’est ajouter aux malheurs de l’entreprise” pourrait-on avancer en paraphrasant le célèbre aphorisme d’Albert Camus.

J’ai ainsi fait beaucoup de recherche pour définir de façon claire et précise les termes innovation, créativité, problème (et résolution de problème), culture ou bienveillance pour m’assurer que mes échanges sur ce sujet partaient sur des bases saines et que mes réflexions n’étaient pas construites sur du sable.

“Ils ne comprennent pas”

Je nous entends souvent maugréer que les managers ou les dirigeants avec qui nous échangeons ne comprennent pas l’agilité et qu’en conséquence ils ne s’y engagent pas avec la détermination qu’on souhaiterait voir. La raison que nous invoquons entre nous est souvent la même : ils ne veulent pas changer. Il s’agit peut-être d’une première piste, mais elle présente l’inconvénient d’être peu actionnable. Une autre piste, que nous explorons  moins volontiers, davantage actionnable, est la suivante : notre façon de présenter et d’expliquer l’agilité est-elle la bonne  ? Ou, dans une formalisation plus ouverte, dans quelle mesure pouvons-nous améliorer notre façon de présenter l’agilité ?

Dans la majorité des cas où j’ai assisté à une présentation de l’un d’entre nous, cela commence immanquablement par le manifeste et les principes. Or, indépendamment de leur qualité ou valeur intrinsèque, le manifeste et les principes ne sont pas une définition. Ils relèvent davantage de l’intention sous-jacente et, regardons les choses en face, du jugement de valeur.

Mon hypothèse est que cela explique pourquoi nos explications mettent nos interlocuteurs mal à l’aise et pourquoi nous perdons alors, dès l’entame de nos présentations, leur écoute. Et tout le monde sait que la première étape du changement est de mettre les personnes en situation d’écoute.

Le pourquoi de l’agilité

C’est regrettable car l’agilité règle un problème essentiel : elle aide à (enfin) sortir des projets informatiques. Nous connaissons tous des exemples de projets de plusieurs millions d’euros qui sont sortis avec des retards considérables pour des coûts plusieurs fois supérieur au coût initial. Ou, encore pire, qui après avoir englouti ces millions d’euros ne sont JAMAIS sortis. Un ami me parlait cet hiver (oui, en 2019) d’un tel projet dans une grande DSI, au coût initial de 2M€ qui a aujourd’hui dépassé les 15M€ et dont on ne sait toujours pas s’il va sortir.

L’étude du Chaos Report de 1995, menée sur plus de 8000 projets IT, montre ainsi que seulement 16% des projets informatiques atteignent leurs objectifs en termes de budget et délais. Dans les grandes entreprises, ce taux de réussite chute presque de moitié à 9%.

Non seulement cela, mais ce faible pourcentage de projets qui réussit ne livre des fonctionnalités qui sont rarement ou jamais utilisées pour les 2/3 d’entre elles (64%). Seules 7% des fonctionnalités livrées par ces projets sont utilisées chaque jour par les utilisateurs et représentent à ce titre de la valeur.

Les fausses croyances du modèle standard

La première raison pour laquelle le modèle standard ne fonctionne pas est parce qu’il est basé sur une croyance forte : celle que le contrôle du plan (ou plutôt l’illusion du contrôle) va livrer des produits représentant de la valeur pour le client. Cette croyance est invalidée par le Chaos Report, année après année.

La seconde raison est parce qu’avec le modèle standard nous devons prendre des décisions structurantes au moment où nous disposons de moins d’informations sur le projet : au tout début. Nous ne sommes alors pas en situation de prendre des décisions informées.

La troisième raison est que la complexité n’évolue pas de façon linéaire à mesure que le nombre d’intervenants augmentent dans une équipe mais selon le carré du nombre. Ainsi dans une équipe à 2 personnes il ne peut y avoir qu’une relation. On passe à 6 relations pour une équipe de 4 personnes et 190 pour une équipe de 20 personnes. Et le cerveau humain n’est pas fait pour intuitivement gérer des courbes non linéaires de second ordre. Ainsi un projet de 10 M€ à 8 fois moins de chance de réussir qu’un projet de 1 M€. Mais l’approche standard nous incite toujours à faire des projets plus grands et ambitieux en perdant de vue cette courbe non linéaire de succès.

Définition des méthodes agiles

Plutôt que la sempiternelle présentation du manifeste et des principes je vous propose plutôt de revenir à une définition. Je vous propose celle-ci que l’on peut probablement améliorer, qui reste sur une dimension purement opérationnelle :

Un ensemble de méthodes de développement produit ou service  [qu’il soit numérique ou pas] ;

1. basées sur des boucles itératives et incrémentales rapides, dans lesquelles :
2. le produit évolue grâce au feedback des utilisateurs ;
3. les besoins changeants sont gérés par la collaboration d’équipes pluri-disciplinaires et auto-organisées ;
4. la mesure d’avancement est la valeur livrée au client [i.e. un incrément de logiciel qui fonctionne, pas une spécification];
5. et où l’équipe dispose d’un espace pour l’amélioration continue.

Nous allons maintenant préciser chacun des termes importants de cette définition et mettre en perspective leurs conséquences concrètes.

Le produit et la valeur

Les méthodes agiles se concentrent sur le produit (car c’est ce qui représente de la valeur pour le client) plutôt que sur la gestion des coûts ou le plan. C’est ainsi que nous passons :

• d’une planification du processus (les grandes étapes étude, analyse, conception, développement, tests, intégration etc … ) avec un pilotage par les coûts, à …
• une planification de la production (à coûts fixes – celui de l’équipe) c’est à dire des incréments de produits, avec un pilotage par la valeur effective livrée.

Itératif et incrémental

L’approche incrémentale permet de livrer des incréments de valeurs au client, à travers des cas d’utilisation complets couverts par le logiciel livré. L’approche itérative permet de s’approcher de la vision client par approximations successives et rapides, car chaque incrément va chercher le feedback de l’utilisateur. La combinatoire permet de faire levier de cette boucle de rétroaction pour livrer de la valeur tout en nous approchant de la vision produit du client.

Ce sont ces incréments “réels” qui servent de support d’analyse, d’échanges et de décision sur le produit au sein de l’équipe. Ce ne sont pas des spécifications qui présentent le risque de de laisser l’espace à de nombreuses spéculations et interprétations. Jason Fried et David Heinemier Hansson expliquent dans leur premier ouvrage Getting Real combien cette approche est importante pour converger rapidement vers un bon produit qui fonctionne.

Valider l’avancement

Ce qui valide l’avancement du projet c’est le retour client sur la valeur livrée à travers les incréments de produit. Ce que nous montre le corpus de connaissance de 30 années de recherche sur le génie logiciel, et ce que met en point d’orgue l’ouvrage le Lean Startup, est que nous n’avons aucune idée des attentes de notre client (et lui non plus d’ailleurs) tant que nous ne lui avons pas présenté votre produit ni demandé son avis.

Pour la valeur, on privilégiera plutôt un focus sur des “Outcomes” (la valeur business), que sur des “Outputs” opérationnels comme l’explique l’auteur de l’ouvrage Lean UX Jeff Gothelf dans cet article.

Equipes pluridisciplinaires

Les méthodes agiles encouragent l’organisation en équipes pluridisciplinaires (que l’on appelle aussi Feature Teams) car celles-ci présentent de nombreux avantages. Elles :

1. suppriment les dépendances externes et donc les attentes qui causent des délais ;
2. sont structurées pour l’amélioration du processus de bout en bout (et accélérer la livraison de valeur au client) ;
3. suppriment les stocks intermédiaires entre fonctions : on ne produit que ce qui est nécessaire pour cette itération ;
4. accélèrent l’apprentissage grâce aux feedbacks quotidiens entre les différents métiers étapes du processus (analyse fonctionnelle, conception technique, développements, tests, déploiement et opérations …)

Chacun de ces points mériteraient un article à lui seul tant les implications sont importantes. Juste un exemple : en intégrant un testeur au sein de l’équipe pour tester au quotidien les deux livraisons quotidiennes, plutôt qu’en le laissant dans son équipe intégration pour tester un fois le contenu de l’itération de développement de 4 semaines livré (un bel exemple de Water-Scrum-Fall), on passe de 1 feedback mensuel à 2 feedbacks quotidiens. On multiplie ainsi par 60 les retours et donc l’apprentissage. Il s’agit d’une des actions majeures qui nous a permis de diviser par 5 la non qualité et par deux les délais dans une équipe R&D de 70 personnes.

Les conditions de l’auto-organisation

Une des convictions de l’agilité est que l’auto-organisation est un levier majeur d’efficacité et d’engagement. Encore faut-il créer le contexte propice à l’auto-organisation. L’agilité crée les conditions de l’auto-organisation en supprimant les causes de complexité grâce à :

1. la réunion de toutes les compétences au sein de l’équipe pour réussir ;
2. des conditions de réussites claires : livrer de la valeur à travers un nombre de User Stories ;
3. une limitation de l’en-cours qui permet d’aligner les efforts de l’équipe et de limiter le multi-tâche, source inépuisable de problèmes de qualité et de délais ;
4. des cycles courts (1-4 semaines) ;
5. la diminution radicale de l’implicite (cause de tant de catastrophes) grâce au management visuel et au pilotage quotidien.

La valeur au coeur de l’opérationnel quotidien

Les méthodes agiles se concentrent sur la valeur livrée grâce à l’unité d’œuvre de l’agilité : la User Story. Un exemple célèbre de Mick Cohn, auteur de nombreux ouvrages de références (dont deux dans le corpus de connaissance du PMI agile) pour illustrer sa pertinence.

Avec des spécifications standard on pourrait définir le produit ainsi :

1. Le produit devra avoir un moteur à explosion ;
2. Le produit devra avoir quatre roues chacune avec des pneus ;
3. Le produit devra avoir un volant ;
4. Le produit devra avoir une carrosserie métallique

En fonction de l’interlocuteur, on va pouvoir imaginer différentes implémentations pour répondre à ces spécifications : une voiture décapotable, un SUV, etc …

Alors que si l’on définit le produit depuis la perspective utilisateur et de la valeur attendue on obtient la définition suivante :

En tant que propriétaire de terrain (acteur) je veux pouvoir tondre ma pelouse en moins de deux heures (action) pour pouvoir y jouer avec mes amis (valeur)

Voilà la puissance de la User Story : elle place la valeur client au cœur de la réalité opérationnelle quotidienne des équipes.

L’amélioration Continue

L’agilité offre un espace (la rétrospective dans Scrum) ainsi qu’un certain nombre d’outils (le PDCA, de Shewart et Deming, étant le plus robuste) pour s’améliorer. Notons qu’il s’agit d’un espace régulier et fréquent, à la différence des post-mortem des projets (qui n’arrivent qu’en fin de cycle) ou ceux menés suite à de graves crises.

Mesurer la performance de l’agilité

Nous savons que les méthodes agiles marchent grâce au Chaos Report qui, dans son édition de 2015 montre que les projets menés en agile ont 4 fois plus de chance de réussir … et 3 fois moins de chance d’échouer.

Mais nous le savons surtout car ces pratiques sont au cœur de la réussite incontestable des géants du numérique qui sont tous, non seulement des acteurs, mais aussi des contributeurs aux pratiques agiles.

Nous le savons enfin car comme nous observons que ces pratiques se généralisent à l’ensemble des industries, bien au-delà des services et produits numériques.

Comment présentez-vous l’agilité à vos interlocuteurs pour les embarquer dans la démarche  ?

o o o

Cet article a été publié dans Culture Kaizen – La transformation des petits matin, livre blanc d’OCTO Technology.