Éclairer le futur est notre métier

Taille du texte: +

"The Link", une interface R/W sur le cerveau

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, démonstration !

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. Inutile de préciser que c'est une excellente performance sur ce réseau social, plutôt fréquenté par des gens sérieux qui cherchent à peaufiner leur réputation professionnelle ;-)

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'analyser le débat et d'essayer de remettre quelques idées sur l'agilité en place, voici des morceaux choisis de cette discussion :

"Construire un vélo pour arriver à faire une voiture c'est de l’argent jeté 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 que cela pour tout le monde, 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 avec la seconde ligne, 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, par exemple avec une voiture décapotable.
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é. Il a été essentiel pour s'adapter à la crise et lors de la généralisation du télétravail. 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 (traduisant la stratégie de l'entreprise). 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, d'où les deux écoles de l'agile. 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 comme cela a été dit, puisque 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 d'où le débat et les incompréhensions. Quand on revient sur celui original d'Henrik Kniberg, coach agile 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. Et bien sûr 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é, car entre l'agile et le cycle en V, il y a beaucoup "d'improvisations" que vous avez certainement vous aussi croisées 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 les standards du PMBOK ou de Prince2, et celui minoritaire qui est adepte du "hors-piste", qu'il ne faudrait cependant pas confondre avec de l'agile !


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

Ce débat c'est 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. C'est également le remplacement de l'électronique par l'informatique dans les machines.

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 ;-)

Monter collectivement en compétences, développer u...
The 14 Best Data Mining Books Based on Real User R...
 

Commentaires

Pas encore de commentaire
Already Registered? Login Here
Guest
mardi 20 octobre 2020

Image Captcha

Copyright © 2020 SLA
167 Chemin des Combes 74110 Essert-Romand - tel : 04.50.83.06.79 - Mobile : 06.75.23.84.11

Mentions légales    -    Politique de confidentialité    -    Plan du site

IMPORTANT

copyright

 Notre blog est un blog de Curation, aussi les articles publiés proviennent-ils de différents flux RSS et nous ne prétendons, en aucune manière, nous en attribuer la paternité. Si vous souhaitez lire l'article original sur le site d'origine, il vous suffit de cliquer sur "Lien d'origine " qu se trouve à la fin de l'article.

Traduire

frendeitptrues

Rechercher

Témoignages

Ils ont assisté à nos séminaires et ils donnent leurs avis.

Ce que les participants en pensent

Programme 2020

Fiche pédagogique

Aller au haut