paint-brush
Les hommes de paille de l'Agilepar@icyapril
5,756 lectures
5,756 lectures

Les hommes de paille de l'Agile

par Dr Junade Ali6m2024/06/25
Read on Terminal Reader

Trop long; Pour lire

Alors qu'un article de revue scientifique a révélé que « les preuves en faveur de la méthodologie Agile sont, au mieux, rares » ; Agile enracine une grande partie de son dogme en opposition à Waterfall et aux succès du système de production Toyota. Cependant, à y regarder de plus près, ce contexte relève plus de la mythologie que de l’histoire.
featured image - Les hommes de paille de l'Agile
Dr Junade Ali HackerNoon profile picture
0-item
1-item
2-item

Du harcèlement jusqu'aux tentatives de piratage, depuis que j'ai commencé à étudier le taux d'échec élevé des projets Agile et des initiatives de transformation, je me suis retrouvé face à face avec le fondamentalisme qui existe parmi les adeptes les plus fervents d'Agile.


Lorsque les patients vulnérables d'un guérisseur succombent à une maladie à la suite d'un traitement factice qui n'a pas fonctionné (après avoir généralement « donné » une somme d'argent considérable), le « guérisseur » prétendra souvent que c'est la faute du patient car il n'a pas prié dur. assez. C'est un sujet longuement exploré par Derren Brown dans l'émission spéciale Miracles for Sale et de manière théâtrale dans son émission spéciale Netflix Miracle . Une telle erreur est souvent décrite comme une version de l’erreur « No true Scotsman » ou un « appel à la pureté ».


Les fondamentalistes de la communauté Agile utiliseront souvent des affirmations similaires lorsque les projets Agile échoueront. Par exemple, dans l'article « Échec en Agile ? Vous faites une erreur », écrit Greg Kihlstrom :

À titre d'exemple, vous pourriez avoir le Scrum Master le plus enthousiaste possible dans votre équipe, mais si l'équipe produit compte des opposants ou ceux qui ne donnent tout simplement pas suite ou ne comprennent pas ce qui doit être fait, vous allez avoir des défis. Parfois, c’est une question d’éducation ou de coaching, et parfois, c’est une question de dynamique et de culture d’équipe. Déterminez quelle est la cause et traitez-la en conséquence.


Cependant, la base scientifique d’une telle croyance n’existe pas. Un article de novembre 2021 intitulé « Meilleures pratiques » sans preuves – Méthodologie logicielle agile comme exemple » a mené une méta-analyse de nombreuses revues d'études scientifiques Agile et a découvert : « Le résultat de l'étude tertiaire est qu'en effet, les preuves en faveur de la La méthodologie agile est, au mieux, rare.


Cependant, c’est loin d’être le seul biais cognitif adopté par ceux qui adoptent une position fondamentaliste en matière d’Agile. Dans cet article, je voudrais me concentrer sur les arguments qui sont souvent utilisés pour justifier la méthodologie Agile.

Qu’est-ce qu’un homme de paille agile ?

Sur la communauté Agile de LinkedIn, il n'est pas rare de voir des messages comme celui-ci - apparemment une conversation qui donne l'impression qu'un praticien Agile a l'esprit vif et justifie la méthodologie face à un ingénieur logiciel qui ose la remettre en question. Mon opinion personnelle est que ces conversations semblent généralement fictives :

Publication LinkedIn de Jem Jelly


L'Oxford English Dictionary fournit la définition suivante d'un homme de paille :

Dans une dispute, un débat, etc. : une proposition intentionnellement faible ou déformée, établie parce qu'elle est plus facile à vaincre que le véritable argument d'un adversaire ou détourne l'attention de celui-ci, donnant l'impression superficielle que l'accusation initiale a été réfutée ou rejetée. .


Cependant, il existe des arguments bien plus profonds qui semblent aller au cœur même de la proposition Agile.


Un article du site SecretGeek posait la question : « L'Agile est-il une religion ? (ou simplement une secte) ». Alors que l'auteur affirmait que les autres éléments dogmatiques de l'Agile étaient effectivement en place, des rituels à la doctrine, le seul domaine sur lequel ils étaient hésitants était de savoir s'il existait une « mythologie » dans l'Agile.


Je crois que ces hommes de paille sont fondamentalement ce qui forme la mythologie de l’Agile.

Le mythe de la cascade

Il est difficile de voir Agile discuté sans discuter de Waterfall. Une prétendue méthodologie de gestion de projet à laquelle Agile s’oppose. Une méthodologie qui nécessite des étapes strictement documentées et sans jamais apporter de modifications.


Cependant, cela soulève la question suivante : où se trouvent les conférences ou les groupes d’utilisateurs Waterfall, même historiquement ?


Peut-être que les origines de la méthodologie nous fourniront quelques indices. Dans les notes de cours de Jon Pearce à l'Université d'État de San Jose, il déclare : « Le modèle de cycle de vie en cascade est l'homme de paille des modèles de cycle de vie. Il a été décrit pour la première fois en 1970 par Wynn Royce comme un exemple de processus défectueux… »


Le développeur de logiciels Christian Findlay a fait un point similaire dans un article sur X déclarant : « L'approche en cascade est un homme de paille qui n'a jamais vraiment existé » .


Cependant, la situation devient plus trouble à mesure que nous approfondissons l’histoire de l’Agile.

Le mythe Toyota

Le Toyota Production System (TPS) est le berceau spirituel de la méthodologie Agile. Malgré l’échec de l’écrasante majorité des initiatives de transformation, nombreux sont ceux qui mettront en avant la méthodologie utilisée par Toyota.


Cependant, Toyota elle-même a une histoire loin d’être idéale en matière d’ingénierie logicielle. Un rapport de Capitol Weekly indique que « sans admettre sa responsabilité, Toyota a réglé depuis 2014 537 réclamations imputant une accélération soudaine à des accidents qui ont tué ou grièvement blessé des personnes, selon un document judiciaire déposé par Toyota » en septembre 2019.


Ces défauts d'accélération involontaires ont non seulement été mortels dans de nombreux cas, mais dans le cas de Koua Fong Lee, le défaut a non seulement conduit à un accident de voiture qui a tué trois personnes et en a blessé d'autres alors qu'il ramenait sa femme enceinte et ses enfants de l'église à la maison, mais a également conduit à ce qu'il soit blâmé et condamné à la prison. Au cours d'une procédure judiciaire, Toyota avait tenté de contrer une théorie expliquant pourquoi le véhicule se comportait de manière erratique en affirmant des protocoles de test robustes, mais peu de temps avant le procès, Toyota a déposé une déclaration de cet ingénieur indiquant que l'entreprise n'avait en réalité effectué aucun test de ce type .


Après avoir refusé d'accepter un accord de plaidoyer qui l'aurait libéré mais l'aurait laissé qualifié de criminel, Lee a finalement été libéré après qu'un nouveau procès ait été ordonné et l'accusation a refusé de renvoyer l'affaire devant le tribunal.


Le cas de Bookout V. Toyota a amené les pratiques d'ingénierie logicielle de Toyota à se concentrer après qu'un autre défaut d'accélération involontaire ait entraîné des décès. Au cours de cette procédure, qui a finalement conclu que les systèmes logiciels pouvaient provoquer une accélération involontaire, des preuves ont été présentées, notamment une communication interne au sein de Toyota indiquant « en vérité, une technologie telle que la sécurité intégrée ne fait pas partie de l'ADN de la division Toyota Engineering » :


À la suite de cette affaire, Toyota aurait adopté une approche traditionnelle de l'ingénierie logicielle pour les projets à haute fiabilité, en utilisant le langage SPARK Ada où des contrats de conception stricts aident à vérifier mathématiquement l'exactitude du logiciel - une approche adoptée dans des environnements à haute fiabilité tels que l'aviation. et la défense.


Cette approche, connue sous le nom de « conception par contrat », a été inventée à l'origine par l'ingénieur logiciel français Bertrand Meyer, qui a lui-même écrit le livre « Agile ! : Le Bon, le Hype et le Truand ». Parmi les critiques de Meyer à l'égard d'Agile figurent la dépréciation de la conception initiale et l'accent mis sur les user stories plutôt que sur les spécifications généralisables.


Ces critiques sont décrites plus en détail dans la vidéo - « The Ugly of Agile (with Dr. Bertrand Meyer) » d'Edensoft Labs :

Conclusion

Les différents hommes de paille d’Agile nous soulignent l’importance que nous devons tous avoir d’être critiques avant d’adopter des solutions qui n’ont pas encore prouvé leur efficacité. Ne vous méprenez pas, nous n'avons pas besoin de méta-analyses de revues systématiques d'essais contrôlés randomisés pour porter tous nos jugements dans la vie, mais nous devons être prudents lorsque nous écartons les preuves d'une base probante plus élevée que celles d'une base probante inférieure ( comme celles qui nous sont présentées comme vérité dogmatique par les figures d'autorité).


En tant qu’humains, les histoires de transformation, malgré les obstacles, nous touchent le cœur, et nous voulons tous croire qu’il existe des super-héros qui peuvent nous guérir. Cependant, le cynisme aveugle peut aussi souvent nous conduire à nous protéger des progrès qui font progresser la société. En cherchant à ignorer ces aspects émotionnels plutôt que de les reconnaître, nous nous retrouvons davantage à leur merci lorsque nous essayons de prendre des décisions rationnelles.


L'une des choses que j'ai trouvées les plus remarquables depuis que j'ai écrit le livre « Impact Engineering : Transforming Beyond Agile Project Management » est la manière dont les plus dogmatiques des deux côtés de la division Agile ignoreront les aspects émotionnels et psychologiques qui constituent en effet l'essentiel de la gestion de projet . le livre et sont, comme les preuves me le montrent, reposent au cœur d’initiatives de transformation véritablement réussies.


Cela nous rappelle brutalement qu’avant d’aller trop loin dans le terrier du lapin, nous devons nous rappeler que les leçons de la science et de l’ingénierie sont que la remise en question de l’orthodoxie et la collecte de preuves sont au cœur de découvertes vraiment remarquables.