Du harcèlement jusqu'aux tentatives de piratage, depuis que j'ai commencé à étudier le 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. taux d'échec élevé 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 et de manière théâtrale dans son émission spéciale Netflix . Une telle erreur est souvent décrite comme une version de l’erreur « » ou un « ». Miracles for Sale Miracle No true Scotsman appel à la pureté Les fondamentalistes de la communauté Agile utiliseront souvent des affirmations similaires lorsque les projets Agile échoueront. Par exemple, dans l'article « », écrit Greg Kihlstrom : Échec en Agile ? Vous faites une erreur À 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é » 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. « Meilleures pratiques » sans preuves – Méthodologie logicielle agile comme exemple 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 : 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 : « ». 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. L'Agile est-il une religion ? (ou simplement une secte) 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 de Jon Pearce à l'Université d'État de San Jose, il déclare : « » les notes de cours 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 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. rapport de Capitol Weekly indique 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 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. avoir refusé d'accepter un accord de plaidoyer 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 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. aurait 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 « ». 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. Agile ! : Le Bon, le Hype et le Truand Ces critiques sont décrites plus en détail dans la vidéo - « » d'Edensoft Labs : The Ugly of Agile (with Dr. Bertrand Meyer) https://youtube.com/watch?v=Xi4WG-FVT6Q 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 « . le livre et sont, comme les preuves me le montrent, reposent au cœur d’initiatives de transformation véritablement réussies. 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 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.
