Agilité, vitesse & biais cognitif

Publié le 04/10/2019

Bien loin de vouloir définir ce qu'est le développement logiciel agile ou plutôt ce qu'il en est devenu, je voulais vous faire part de mon triste constat quant au décalage existant entre ce que contenait de simple et bon le "Manifeste" et la confusion qui règne aujourd'hui jusque dans les boîtes industrielles de nos campagnes.

Vous me direz que le dit décalage est logique car, entre ce que disait un certain prophète sur une colline il y a 2 000 ans et les déclarations de ses fidèles aujourd'hui, il y a certainement un léger delta. Bien qu'étant le premier à accepter que tout s'accélère, on parle désormais d'un delta équivalent (ou supérieur) mais sur une période de seulement 20 ans. L'exponentialité de cette courbe ne nous laisse donc rien présager de bon pour la prochaine bonne idée et les 20 minutes qui suivront...

Petit rappel des faits

Depuis 1970, un projet logiciel, informatique, numérique ou assimilé est souvent exécuté de façon cascadée (d’où le nom "waterfall") et une succession d’étapes s’enclenche. Elles se déroulent les unes derrière les autres jusqu’à la sacro-sainte livraison (et le PV de recette final) déclenchant la facturation finale et la volonté (ou non) des parties prenantes à déclarer le projet comme une réussite (ou un échec).

Audit, expression de besoin, ateliers, spécifications fonctionnelles, design, spécifications techniques, architecture, infrastructure, développement, tests, recette, déploiement... (mettez en plus, changez l’ordre,... comme vous voudrez). Entre chaque étape, il y a bien souvent une validation, voire des validations de validations... Chaque étape contient en elle-même son propre ensemble d’étapes... On produit des documents (budget, planning, RACI...) remplis de choses qui seront rapidement obsolètes au fur et à mesure du projet. On se tape dans le dos, on se dit des : "j’adore ce que vous faites" lors de réguliers et bien trop fréquents copil, codir, coproj, cobordels... Bref, tout le monde prend un facétieux plaisir à faire durer les projets pour justifier un salaire, une prestation, un taux jour, une présence, un droit de veto. Certains s’évertuent à expliquer que tout cela est complexe et que c’est la gestion de l’humain qui prend du temps mais qui est un gage indiscutable de réussite. Tout le monde dodeline du chef et on convient de se revoir pour "en re-discuter".

Aux alentours de 1995, c’est l’arrivée du web, la démocratisation de l’ordinateur personnel et l’accessibilité des connexions domestiques à l’Internet. Très rapidement, devant l’obscurantisme ambiant dans les salles de marchés et la présence de capitaux disponibles, quelques "petits génies" font et défont des fortunes en quelques années. En mars 2000, c’est l’explosion de "la bulle Internet". Au passage, c’est la découverte, pour tout un pan de l’économie "traditionnelle", que l’on peut mettre en ligne une application web sans passer par toutes les étapes précitées et gagner de l’argent relativement rapidement. C’est le début de la compréhension du "hack de la distribution" et l’avènement du "cut the middleman". Mais c’est un autre sujet...

En octobre 2000, à Minneapolis, a lieu OOPSLA (Object-Oriented Programming, Systems, Languages & Applications), une conférence qui aborde les différents aspects du développement logiciel.

Lors de cette conf, une brochette de 17 mecs se dit, puisqu'on en est tous à gueuler sur les trucs qui vont pas dans le développement logiciel, pourquoi ne ferions-nous pas un petit atelier dans quelques temps. On parlerait des valeurs qui nous semblent plus importantes que d'autres et bon, dans le pire des cas, on passera un bon moment.

Les gars (Alistair Cockburn, Andrew Hunt, Arie van Bennekum, Brian Marick, Dave Thomas, James Grenning, Jeff Sutherland, Jim Highsmith, Jon Kern, Ken Schwaber, Kent Beck, Martin Fowler, Mike Beedle, Robert C. Martin, Ron Jeffries, Steve Mellor, Ward Cunningham) sont tous, je vous laisse Wikipedier les noms, des professionnels en sciences de la computation comme on dit outre-atlantique.

Ils accouchent d'une page web qui proclame :

"Manifeste pour le développement Agile de logiciels

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers."

En résumé : un truc sympathique, inoffensif, pas prétentieux, plutôt consensuel et plein de bon sens. S'en suivent une douzaine de principes rédigés par les mêmes mains. Les gars rentrent chez eux, contents de leur weekend.

---

C’est l’intention qui compte

En dehors de toute logique qui déclarerait que tout ce qui n'est plus hipster, est forcément has-been ; l'agilité, les pratiques agiles ou bien encore le développement logiciel agile (là n'est pas le débat) sont arrivés au point où tout le monde en fait. On en fait plus ou moins, plus ou moins bien ; ou plus ou moins souvent.

Puisque tout le monde "fait de l'agilité", ça n'existe plus vraiment en tant que tel. Ce qui était différenciant, n'est pas pour autant syndicalisant lorsque tout le monde en fait. Un truc cool n'est plus cool quand tout le monde le trouve cool. Restez avec moi.

Mais surtout, on en fait désormais dans les PME et ETI. Entreprises qui, pour certaines, en plus de cultiver des pratiques managériales des années 30, en parlent comme quelque chose d'obscur mais sûrement puissant, bien qu'angoissant. Désormais, "l'agilité" pour ceux qui osent dire son nom à haute voix, est devenue une sorte de légende dont on a entendu parlé à plusieurs reprises et que chacun vient faire grossir en y ajoutant sa touche de : "Incroyable, ils ont codé ça en 2 jours !". Le flou est entretenu autour du "ça" : s'agissait-il de maquettes, d'un POC, d'un MVP, d'une API ou de tout autre acronyme encore difficile à déchiffrer au comex ? A la Cogip, le mystère demeure.

Par conséquent, qu’il s’agisse d’une entreprise du CAC40, de la tôlerie du coin, d’une ESN ou d’une petite agence créative et agile, tout le monde "fait de l’Agile". Il n'y a plus que les intentions qui divergent.

On pourrait donc crier victoire et se dire, qu'enfin, #lesGens vont moins souffrir dans les projets informatiques. Qu'on va enfin être en mesure de sortir des produits (logiciels, applications... bref, du code) sans énorme décalage, fonctionnel ou temporel, entre le besoin initial et la livraison finale. Que le coût dans tout ça, s’en retrouvera impacté positivement (pour les clients) ou que l’engagement de réussite qui était imputable à l’approche forfaitaire ne le sera plus (pour les fournisseurs). Qu’on ne va plus écrire (ni lire) de specs (ou bien beaucoup moins).

Vous l'aurez deviné, non. Il n'en est rien. Rien n'est gagné (ou très peu) car encore beaucoup sont déçus lorsqu'ils sont livrés (s'ils sont livrés). Les délais, les coûts et la qualité ne sont pas plus garantis en "pratiquant l’agilité" (on dirait vraiment une religion) qu’en faisant "à l’ancienne". Les parties prenantes, peu importe les contextes, ne se font pas forcément moins mal. Le seul point sur lequel tout le monde est à peu près unanime, c’est qu’on sait désormais beaucoup plus rapidement si ce qu’on est en train de concevoir va être cool ou non. Et c’est déjà beaucoup.

Ce sont bien souvent les mêmes personnes qui vous expliquaient, il y a 2 ans, pourquoi il était essentiel que la spécification fonctionnelle d’un site web de 12 pages fasse 278 pages et soit signée par l’entièreté du collège des décideurs d’une entreprise pour que le projet soit mené dans des conditions "normales", qui vous disent aujourd’hui que : "L’agilité, c’est la seule voie."

Ce sont les intentions des clients et des fournisseurs (et donc forcément la perversion humaine cachée derrière celles-ci) qui affectent ce que le manifeste portait de bon.

Les premiers aiment l’idée d’agilité car ils la relient à la vitesse et au fait qu’ils n’auront pas de specs à valider, mais veulent un devis pour une prestation au forfait.

"On veut bien y aller petit bout par petit bout sans tout écrire à l’avance mais si vous pouviez nous chiffrer la totalité du budget, ça aiderait bien la finance chez nous parce que bon, on doit voir si c’est de l’opex ou du capex."

Capex qui revient à considérer que le code, c'est de l'investissement et finit donc, inexorablement, par être de la "dette technique". Article sur le sujet écrit par Quentin Adam.

Les seconds aiment l’idée qu’on peut enfin vendre du jour-homme ad vitam eternam, car ça y est, l’idée qu’un projet ne s’arrête jamais vraiment a été intellectuellement intégrée.

Ce n’est pas le degré d'agilité, la méthode choisie ou le choix de votre plateforme de ticketing qui fera que votre projet de développement sera agile ou non. C’est l’alignement des intentions des différentes parties prenantes qui décidera de l'agilité de votre projet.

En résumé, on "fait de l’agilité" comme on "fait du bio". Sous couvert d’une vague conscience philosophique, chacun continue de voir midi à sa porte.

Hier j'écoutais quelqu'un me dire : "Non, mais l'agilité, pour que ça marche, ce n'est pas que le développement qui doit être impacté mais toutes les fonctions : les RH, la compta, le support, les ventes, le marketing...". Bien que foncièrement bien intentionné, ce discours me rappelle celui des témoins de Jéhovah qui se sentent sauvés/élus (rayez la mention inutile) et qui veulent prêcher la bonne parole pour que les autres aussi soient sauvés et rejoignent à leur tour la grande secte de l'agilité lorsque Skynet arrivera.

Son intention, c’est que tout le monde (chez le fournisseur) "soit agile". Est-ce que les clients seront partie prenante ? Est-ce qu’on va plus se parler que de produire des docs que personne ne lira? Y a-t-il des parties du livrable qui seront facilement modifiables? Pas sûr.

Sans aller jusqu’à ce que toutes les fonctions d’une même entreprise s’ancrent dans la même logique, le fait que les parties prenantes d’un projet soient raccord sur les intentions est une étape importante. Probablement la première à passer.

---

On a (encore) cassé un truc bien

Le manifeste aurait pu être une source d'inspiration meta. Un truc beau et que les gens liraient à voix haute en kickoff histoire de, une ode à la collaboration et à la bonne santé des projets, une chanson de marins-développeurs remontant les casiers à bugs, une sympathique biguine qui mettrait une ambiance collé-serré entre les différentes parties prenantes d'un projet.

En vrai, tout ça a été violenté, pillé, liquéfié, oublié. Chacun y est allé de sa méthode, de son acronyme, de sa querelle de chapelle, de son bullshit-bingo. En oubliant, à mon avis, l'essentiel : la satisfaction d’un travail collectif basé sur l’échange et facilement modifiable. Ce, impliquant forcément, de petites itérations régulières, en petits comités.

De la même façon que chaque nouvelle invention marketing finit par être détruite par l'obsession des marketeurs à exploiter outrancièrement celles-ci jusqu'à leur inefficacité (prospectus, mailing papier personnalisés, phoning, bannières, emailings, cold emails, vidéos, native ads, publi-rédactionnel, Adwords, marketing d'influence...) et de dire ensuite que "ça ne marche plus si bien que ça", l'agilité en a pris un bon coup dans les chicots.

En somme, "l’agilité" s’est faite marketer. Ça a rapidement été utilisé par les plus vifs et vaillants : les consultants indépendants. Ça a ensuite été très rapidement adopté par les startups ou pseudo-startups et enfin par les agences (petites ou très grandes). Ça a malheureusement fini par rassembler à ça :

• - Donc, vous faites des applis web, c’est ça ?
• - Oui, mais les nôtres, elles sont agiles.
• - Ah ouais, vachement bien. Bah je vais vous en prendre un peu alors.
• - Y en a un peu plus, je vous le laisse. Au pire, on passera ça en jours de maintenance.

Est-ce que c’est mieux ? On ne sait pas vraiment. Mais c’est agile. Tout comme le mot "digital" s’est fait, pardonnez du peu, "naturaliser français contre son gré", le mot "agile" n’a pas fini d’être prononcé à tort ou à raison par les premiers pécores venus.

• - Et vous, vous faites de l'agile ?
• - Nous, on fait du kanban.
• - Bah nous, on fait du scrum.
• - Scrum c'est bien, mais SaFe, c'est mieux.
• - Ma grand-mère fait du Yolo.
• - Nous c'est pas pareil. On fait du cycle en V ultra-haute fréquence. Vous ne pouvez pas comprendre. C'est au-dessus de l'agilité.
• - ...
• - Nous on fait du cycle en V, et finalement, on a le même taux de suicides que chez nos concurrents.

Ça m'en touche une sans faire bouger l'autre pour tout vous dire. J'en ai tellement entendu et vu sur les uns, les autres, les process, les outils, les soi-disant cultures de ceci ou de cela, les certifications machin, les coaches truc, les experts bordel... qu'aujourd'hui, la seule chose que je valorise c'est : est-ce qu'il y a un truc en prod qui est utilisé par au moins une personne ?

Oui, la méthode importe. Néanmoins, dire ça c’est un peu comme tous les gens qui voyagent les poches pleines de billets et qui te disent droit dans leurs bottes : "Nan, mais ce n’est pas la destination qui compte, c’est le voyage." Oui, bah fais trois semaines de dromadaire dans le désert et on en reparle...

Dans les projets, c’est un peu pareil, oui, c’est bien si on peut prendre un chemin où on arrive à emmener tout le monde sans en perdre en route mais c’est quand même important d’arriver à destination. La grosse différence avec l’agilité, c’est qu’on ne connaît pas la destination. Les projets auto-proclamés agiles qui vous montrent une maquette du produit final, n’en sont pas.

Comme le rappelle superbement Dave Thomas dans son article ET dans ses différentes conférences suite à l'article : Agile is Dead (Long Live Agility)

"Finalement, l’agilité se décompose en 4 mouvements :

1. Découvrez où vous êtes
2. Faites un pas vers votre objectif
3. Ajustez votre compréhension en fonction de ce que vous avez appris
4. Répétez

Face à deux alternatives ou plus, offrant la même valeur, prenez le chemin qui facilite les changements futurs."

Si et seulement si ces 4 étapes et cette façon d’appréhender la prise de décision sont acquises, alors vous pouvez commencer à imaginer comment accélérer. Mais en aucun cas ça ne précise qu’un sprint de 2 semaines est meilleur qu’un sprint de 3 (ou l’inverse).

Et c’est là que le biais cognitif autour de l’agilité se crée. On est "agile", donc on va vite, donc ça coûte pas cher. Donc, si c’est de la merde, c’est pas grave parce que ça coutera pas cher de tout foutre à la poubelle. Et c’est probablement à cause de ce biais que tout a sombré car la relation client-fournisseur étant ce qu’elle est, notamment en France, les premiers ont dû évoquer le biais, les seconds n’ont pas contredit et tout s’est barré en sucette.

Il n’empêche que tout cela dépend énormément des contextes. Une entreprise, un projet, un produit, une équipe sera plus ou moins à l’aise, efficace ou productif en travaillant d’une manière ou d’une autre. Ce n’est pas la manière qui est bonne ou mauvaise, c’est la capacité à changer de méthode si celle-ci ne convient pas qui est fondamentale.

Etant plus un héraclitien convaincu qu’un parménidien sceptique, je crois au changement permanent et universel. Donc, cette mauvaise passe dans laquelle nous sommes en train de nous fourvoyer fera bientôt place à une nouvelle hype peut-être plus sympa encore. Mais je crois aussi à la cyclicité, à l’accélération permanente, et je me dis que l’on reproduira cette erreur mais qu’elle durera moins longtemps. Bref, espoir.

N’apprenez pas telle ou telle méthode, mais apprenez à apprendre de plus en plus vite.