Vérité inconfortable sur les transformations agiles | Ordinateur hebdomadaire

Au cours des derniers mois, j’ai travaillé avec un psychologue clinicien expérimenté et une équipe de recherche titulaire d’un doctorat comprenant un psychologue et un spécialiste du comportement universitaire pour comprendre ce qui différencie les équipes les plus performantes de celles en difficulté. Des recherches montrent que 81 % des décideurs d’entreprise au Royaume-Uni et 89 % aux États-Unis sont préoccupés par la situation. livraison à temps des projets logiciels dans leurs organisations.

Ce travail a été réalisé dans un contexte où l’industrie s’est généralement concentrée sur l’amélioration du processus de test des logiciels, l’une des dernières étapes du cycle de vie du développement logiciel, pour résoudre ces problèmes. De plus, de nombreuses entreprises se tournent de plus en plus vers l’étude des paramètres de la façon dont les logiciels eux-mêmes sont écrits afin de tenter d’améliorer le processus d’ingénierie logicielle.

Les défis semblent cependant encore plus profonds que lorsque le code est écrit ou testé.

Quand j’ai écrit mon dernier livre, Comment vous protéger contre les ordinateurs tueurs, j’ai étudié en profondeur un certain nombre de pannes logicielles catastrophiques, notamment des avions entrant en plongée mortelle, des accidents de voiture mortels et des surdoses de radiations mortelles dans les hôpitaux. Le livre décrit comment facteurs psychologiques nous aident à comprendre pourquoi les bugs logiciels se transforment en pannes informatiques catastrophiques. Cependant, un thème récurrent et alarmant dans de nombreuses études de cas est que la cause technique initiale de nombreux problèmes était des problèmes de conception logicielle, ou même le manque de conception robuste.

Cette approche légère a été formalisée dans le Manifeste Agile, vieux de plus de 23 ans, qui préconisait une approche de conception logicielle centrée sur la réponse aux changements en suivant un plan.

Avec la société de sondage JL Partners, j’ai interrogé 600 ingénieurs logiciels au Royaume-Uni et aux États-Unis sur les projets de développement logiciel réussis et échoués sur lesquels ils ont travaillé. Nos recherches ont révélé que dans les projets logiciels où le développement commençait avant des exigences claires, où il n’existait pas de document de spécification complet et où des changements importants intervenaient tard dans le développement, les projets échouaient dans 65 % des cas.

Cependant, nous n’avons identifié que cinq pratiques d’ingénierie qui ont réduit le taux d’échec à 10 %. Avoir des exigences claires avant le début du développement rendait les projets 97 % plus susceptibles de réussir et les ingénieurs ayant la liberté de discuter et de résoudre les problèmes augmentaient les taux de réussite de 87 %. D’autres pratiques comprenaient : s’assurer que les exigences étaient adaptées au problème du monde réel (54 %) ; avoir une spécification complète avant de commencer le développement (50 %) et éviter les modifications tardives des exigences (7 %). Lorsqu’elles sont combinées, nous désignons ces pratiques comme Ingénierie des impacts.

Il est intéressant de noter que nous n’avons pas trouvé de différence statistiquement significative entre ceux qui travaillent simultanément sur plusieurs projets et ceux qui ne travaillent que sur un seul à la fois, bien que la limitation du travail en cours soit un principe clé des cadres tels que le développement de logiciels Lean. Cela met en évidence la manière dont les risques précoces dans les projets logiciels doivent être pris en compte.

Il était inquiétant de constater que la plus grande différence dans les pratiques d’ingénierie entre le Royaume-Uni et les États-Unis était que les ingénieurs logiciels du Royaume-Uni étaient 13 % moins susceptibles de penser qu’ils pouvaient discuter et résoudre les problèmes que ceux des États-Unis. C’est malgré de nombreuses études menée par moi et d’autres, y compris cette recherche, soulignant à quel point la sécurité psychologique est fondamentale pour le succès des systèmes informatiques.

Au cours de nos recherches, nous avons également examiné pourquoi les initiatives de transformation échouent. Malgré la promesse des méthodologies de transformation, nous constatons toujours que 70 % des transformations numériques et 96 % des transformations agiles échouent. Même parmi toutes les entreprises, quel que soit leur secteur d’activité, lorsqu’une entreprise entre en redressement judiciaire en Angleterre et au Pays de Galles (c’est-à-dire qu’un praticien de l’insolvabilité en prend le contrôle), seules 10 % des entreprises survivront malgré le changement de direction.

Nos recherches ont montré que des facteurs psychologiques fondamentaux jouent un rôle déterminant dans la réussite ou l’échec de telles transformations. Cela a été démontré dans une étude menée par EY (Ernst & Young) et l’école de commerce de l’Université d’Oxford, qui a révélé que les dirigeants qui donnent la priorité aux émotions du personnel ont 260 % ​​plus de chances de réussir les transformations numériques.

Tout comme pour réconforter un bébé qui pleure, il est essentiel d’accorder une attention émotionnelle avant d’aborder le problème réel. Il est également important de veiller à ce que les facteurs émotionnels ne soient pas négligés dans les transformations organisationnelles.

Des conclusions similaires ont été faites par le psychologue David DeSteno, qui a découvert que le simple fait que les participants à l’étude ressentent l’émotion de gratitude, ils ont plus que doublé leur capacité à retarder la gratification maintenant pour une récompense plus importante plus tard.

Grâce à des recherches comme celle-ci, nous avons développé un cadre psychologique permettant aux gens de réaliser des transformations personnelles et organisationnelles significatives. Ces techniques sont présentées dans mon nouveau livre, Ingénierie d’impact : transformer au-delà de la gestion de projet agilequi décrit son application à des études de cas réels ainsi que la base scientifique de ces résultats.

Cependant, je tiens à souligner qu’il est essentiel que cette recherche ne soit pas utilisée à mauvais escient pour forcer les autres à changer lorsqu’ils ne le souhaitent pas. Dans de nombreux cas auparavant, les partisans de la transformation n’ont pas tenu compte de la nécessité absolue du consentement, tant pour les individus que pour les organisations.

Les problèmes moraux mis à part, priver quelqu’un de la capacité d’apprendre de ses propres erreurs le prive d’une source importante d’apprentissage dont il peut bénéficier (dans la mesure où il a donné son consentement éclairé pour commettre ces erreurs et ne représente pas un risque absolu pour les autres).

De plus, comme l’ont montré nos recherches sur l’agilité, ceux qui ont la plus grande conviction dans leurs idées peuvent se tromper. Nous devons aborder les situations avec un esprit ouvert, même si nous sommes convaincus d’avoir raison.

Néanmoins, en veillant à ce que les problèmes soient bien définis avant de chercher des solutions et en veillant à concevoir des solutions avant de commencer à les mettre en œuvre, nous sommes en mesure d’améliorer le succès de nos projets logiciels. De même, en veillant à répondre aux besoins émotionnels tout en résolvant les problèmes, nous sommes en mesure de garantir le succès des initiatives de transformation.

Le Dr Junade Ali CEng FIET est un technologue expérimenté qui s’intéresse à la gestion du génie logiciel, à la recherche sur la sécurité informatique et aux systèmes distribués.