L’agilité fait toujours débat

L'agilité fait toujours débat

Dans la majorité des enseignements sur l’adaptation des entreprises à la crise sanitaire, que l’on trouve par-ci ou par-là on parle d’Agilité. Mais tout le monde a-t-il la même définition de l’agilité et de l’adaptation des processus pour être plus agiles ? Au moins pour ce qui concerne le développement informatique, pourtant précurseur sur ce sujet, GreenSI n’en est vraiment pas sûr !

C’est une discussion qui a commencé sur LinkedIn. Elle a rapidement confirmé que 10 ans après ses débuts, le débat sur les bénéfices de l’agilité, sur comment s’y prendre et pourquoi l’agilité n’est pas contradictoire avec les méthodes traditionnelles, est toujours présent. Un simple schéma a déclenché un débat en 120 commentaires suivis par 462 personnes – quand GreenSI a arrêté de le suivre. C’est une excellente performance pour une simple image sur ce réseau social plutôt fréquenté par des gens sérieux qui cherchent à peaufiner leur réputation professionnelle 😉

publicité

Tout a commencé avec un de ces schémas qui circulent régulièrement sur les réseaux sociaux, voulant capturer la différence entre l’agilité et le fameux “cycle en v” des méthodes traditionnelles, ou chute d’eau comme le désignent les Anglo-saxons (waterfall).

Avant d’analyse le débat et d’essayer de remettre les idées en place, voici quelques morceaux choisis dans cette discussion :

  • Construire un vélo pour arriver à faire une voiture est de l’argent jeter par la fenêtre.
  • Le premier schéma montre des étapes de fabrication d’un produit ; le second, une suite de produits. Les deux n’ont rien à voir ensemble.
  • Si le besoin est initialement de se déplacer plus rapidement qu’à pied, il me semble qu’on peut considérer la planche à roulettes comme un précurseur de la voiture.
  • On crée une confusion importante en montrant qu’à la fin on produit une voiture qui semble très standard et qu’on aurait sans doute pu choisir « sur catalogue »
  • Au début, on voulait un véhicule à 4 roues pour qu’une personne puisse se déplacer sans polluer… À la fin on a une bagnole… On peut aussi appeler ça la dérive de l’Agile…

Ce schéma n’est visiblement pas si explicite et pose le débat sur les méthodes de fabrication, et pourquoi choisir ou ne pas choisir l’agile.

On y retrouve bien avec la première ligne une construction “waterfall” progressive et une agilité qui teste plusieurs fonctionnalités de mobilité avant d’arriver à la même voiture (on y reviendra). La schématique de l’agilité utilisée est celle de Henrik Kniberg. Elle résume 3 des 4 principes du manifeste agile, à la base du développement de l’agilité depuis 10 ans :

  • #2 : des logiciels opérationnels plus qu’une documentation exhaustive :
    à chaque étape, on livre bien quelque chose d’opérationnel qui fonctionne (comme la patinette) et non la spécification de quelque chose de plus ambitieux (la voiture) que l’on aurait pas sus construire dans le même laps de temps. Une des limites du schéma est d’ailleurs de ne pas montrer le temps, mais des étapes dont on ne sait rien de la durée. Quatre pour le waterfall, cinq pour l’agilité, elles induisent la rapidité du premier, ce qui n’est pas obligé.
  • #4 : l’adaptation au changement plus que le suivi d’un plan :
    on avait aucune idée que l’on allait faire une voiture en étape 5 quand on a posé les bases du skate board en étape 1. C’est par adaptation progressive et par interaction avec le client – valeur de l’usage – que l’équipe agile est arrivée à “l’évidence” du design de la voiture. Ce qui suggère le principe suivant pour orienter la conception.
  • #3 : la collaboration avec les clients plus que la négociation contractuelle :
    le processus collaboratif agile permet d’imaginer des solutions qu’il aurait été compliqué de négocier contractuellement dès le départ. Elles ont été imaginées en cours de route, avec de nouveaux retours du client, qui ne figurent pas dans le cahier des charges initial (une solution de mobilité). C’est pour cela que l’agile n’a aucune chance d’aboutir sur la même voiture que le waterfall, qui elle a été imaginée dès le départ. L’agile est clairement préconisé dans les univers incertains, d’où le consensus actuel comme atout dans un monde post-COVID.
Notons que le premier principe agile (#1 : les individus et leurs interactions plus que les processus et les outils) n’est pas représenté. On le retrouve cependant dans le débat, car l’analyse des commentaires par GreenSI fait ressortir qu’il y a ceux qui pensent que l’agilité est une méthodologie totalement déterministe, donc outillée et fortement structurée, et ceux qui voient l’agile comme elle a été lancée, avec des principes presque philosophiques, qu’il faut décliner tous les jours avec son équipe avec son client ou avec ses fournisseurs.

Les premiers (agilité bien structurée) suivent certainement avec intérêt les travaux de SAFE, pour Scale Agile FramEwork, donc une agilité à l’échelle d’une DSI ou d’un département. SAFE est un framework qui cherche à s’imposer comme la méthodologie agile complète, pratiquée au niveau des équipes, des programmes, jusqu’à la gestion des portefeuilles de projets (stratégie). Cette approche globale demande forcément de normaliser et de mettre des processus sur le travail des équipes, là où les seconds préfèrent reposer sur le jugement humain de chaque équipe et une adaptation dynamique. Henrik Kniberg, l’auteur du schéma qui a été détourné, comme on va le voir, a d’ailleurs simplifié la vision de SAFE de façon intéressante (le poster original SAFE 5.0 est un tantinet plus complexe – ici)

Finalement, ce qui fait peut-être le plus débat sur LinkedIn, ce sont peut-être les étapes du waterfall et leur comparaison avec l’agile.

Le schéma est clairement réducteur des méthodes traditionnelles basées sur une conception d’ensemble de la voiture finale, et il prête à confusion sur les étapes qui suggèrent une construction (donc une conception) modulaire, sans réelle finalité pour chaque étape.

Tout ce que l’on peut dire, c’est que, par rapport à l’agile, il n’y a pas de valeur pour le client à être livré d’une roue ou d’un châssis, avant de recevoir sa voiture. On ne peut pas non plus tester ces composants séparément, car une roue libre ne préfigure en rien quatre roues qui supporteront 500 kg, et elle ne veulent rien dire pour le client qui attend sagement sa voiture.

Et puis compte tenu du fait que l’agilité à “découvert” la voiture après 5 itérations enrichie par l’expérience dess clients, il y a peu chance que la voiture produite en waterfall soit la même que celle produite en agile.

Bref ce schéma waterfall est très incomplet. Quand on revient sur celui original d’Henrik Kniberg qui dans les premiers a évangélisé l’agilité avec la construction d’une voiture, on voit que la séquence en 4 étapes explique… ce qui n’est pas agile. Elle ne représente donc pas le cycle en V comme indiqué dans le schéma qui a fait débat. Tout ce qui n’est pas agile n’est pas cycle en V ! 

D’ailleurs, c’est peut-être pour cela que le taux d’échec des projets reste toujours élevés, car entre l’agile et le cycle en V, il y a beaucoup “d’improvisations” que vous avez certainement vous aussi constaté, et qui font du mal aux deux démarches.

On a donc quatre écoles identifiées dans cette discussion que GreenSI essaye de résumer dans le schéma ci-dessous (soyez indulgents !) en prenant en compte si on préfère l’incrémental ou pas, et si on préfère les processus ou pas :

  • Les adeptes de l’agilité “originelle” et du manifeste agile.
  • Ceux qui préfère l’agilité à l’échelle et s’appuient certainement sur SAFE.
  • Ceux qui ne pensent que l’agilité n’est pas adaptée à leur projets?
    Avec deux courants, celui majoritaire qui s’appuie sur le cycle en V et celui minoritaire qui est adepte du “hors-piste”, qu’il ne faudrait cependant pas confondre avec l’agile !

Un autre débat dans le débat a aussi eu lieu et aborde les liens entre les mondes physique et numérique.

Celui de savoir si l’agilité était adaptée au monde industriel, où Henrik Kniberg est allé piocher sa voiture pour illustrer le développement logiciel. En effet le concept de MVP – Minimum Viable Product – à la base des itérations agiles pour le développement de logiciels, créé du gaspillage quand on l’adapte en permanence à des objets physiques qu’il faut construire et déconstruire.

Sans vouloir généraliser, Elon Musk nous montre cependant qu’une vision industrielle et agile à grande échelle est possible, elle est traitée dans deux billets de GreenSI, avec Tesla (Un modèle industriel et agile) et Neuralink (The link, une interface R/W sur le cerveau). Ce dernier attire l’attention sur l’importance majeure de la conception d’ensemble initiale et l’importance des interfaces pour anticiper les évolutions de systèmes physiques et en changer des composants. Ainsi, les voitures Tesla reçoivent des mises à jour logicielles pouvant aussi modifier le fonctionnement physique de la voiture, par exemple l’autonomie, la protection antivols ou le pilotage automatique.

Une autre approche est de virtualiser le physique, donc de rendre logiciel tout ce qui est physique. C’est ce qu’il se passe avec les datacenters et qui a permis, avec DevOps, de repousser les limites physiques de l’exploitation informatique.

L’agilité semble donc bien installée et ses bénéfices clairs, ce qui ne veut pas dire qu’elle est la solution à tout. Cependant la vision de GreenSI serait plutôt qu’elle se déploie dans de plus en plus de domaines, bien en dehors du logiciel, quand les utilisateurs renoncent à leurs certitudes et adoptent une approche itérative des solutions. Les derniers articles “post-COVID” de plusieurs de cabinets de conseil en stratégie ou Université de management, comme le MIT avec Reboot your strategy, appellent d’ailleurs à “une nouvelle conception organisationnelle qui favorise la libre circulation de l’information qui encourage l’innovation, la collaboration et l’interaction”…

Si on est pas en train d’écrire un nouveau manifeste agile de toute l’entreprise, GreenSI ne s’y connais plus 😉

Leave a Reply

Your email address will not be published. Required fields are marked *