Les DSI parlent agile : échouer vite et apprendre encore plus vite

Dans un récent Harvard Business Review, K. Gardner et Alia Crocker écrivaient que « pour que l’Agile fonctionne, les dirigeants doivent choisir les bonnes personnes ». Sinon, les organisations « ne manqueront pas seulement d’atteindre leurs objectifs, elles provoqueront également des perturbations au sein de l’organisation.

Une initiative mal gérée peut rater des échéances critiques, ralentir le développement des produits et entraîner l’épuisement professionnel du personnel, la perte de talents clés et des conflits entre équipes. » Les organisations informatiques étant généralement à l’avant-garde de l’adoption de l’agile, que pensent les DSI de cette méthodologie ? Et où en sont-elles dans son adoption ? Un récent CIOChat event s’est penché sur le sujet.

À lire aussi : Guide de la transformation numérique : définition, exemples et stratégie

Intégrer les pratiques agiles, le design thinking et l’innovation

D’après les commentaires publiés sur CIOChat, les DSI ont de bonnes nouvelles pour Gardner et Crocker. Elles estiment que leurs organisations sont déjà bien avancées dans l’intégration de l’agile.

Par exemple, le DSI Justin Bauer explique : « notre organisation connaissait l’agile à mon arrivée, mais elle en a désormais pleinement adopté les principes fondamentaux. Les projets pilotés par l’IT sont maintenant tous agiles. La direction apprécie que la valeur soit déployée en continu. En matière de conception, notre entreprise a toujours eu une vision à long terme. Désormais, nos projets sont alignés sur des objectifs de long terme, tandis que nous publions des mises à jour inspirées de sprints de 4 semaines, qui apportent une valeur significative. »

Pour parvenir au résultat décrit par Bauer, l’ancien DSI Isaac Sacolick estime que les organisations informatiques doivent « planifier et exécuter par sprints. Tout aussi important, la conception doit comprendre les propositions de valeur pour les clients et intégrer ces connaissances à la planification. Enfin, l’innovation doit être équilibrée par rapport aux préoccupations de sûreté et de sécurité. »

Sacolick poursuit en affirmant que « si l’agile n’est utilisé dans l’IT que pour améliorer l’exécution des projets, il est très difficile de piloter la transformation de l’entreprise. Le numérique exige une planification, une exécution et des boucles de rétroaction itératives, ce qui explique pourquoi l’agilité est si essentielle à la réussite d’une transformation. L’agile doit donc s’accompagner d’un changement de culture, à la fois dans l’IT et dans l’entreprise. » Avec le recul, Sacolick déclare : « il n’est pas surprenant que le taux d’échec des projets informatiques ait été d’environ 80 % avant que l’agile ne change la donne. Vous souvenez-vous de ces longs documents d’exigences et de ces procédures de changement complexes ? »

Même les DSI qui rejoignent une nouvelle organisation devraient lancer l’agile immédiatement. La DSI Paige Francis explique qu’elle « débute tout juste ici, mais je définis des feuilles de route avec des avancées successives et l’intention de célébrer chaque victoire rapide. Chacune contribue à une conception globale, à une vision d’ensemble. Si la durée entrave les progrès ou accroît l’épuisement, alors oui. »

En ce qui concerne les résultats de l’entreprise, l’ancienne DSI Joanna Young explique : « dernièrement, j’ai déployé l’agile en faisant évoluer des données anciennes et dégradées vers des visualisations à jour, plus saines et utiles, et donc vers une prise de décision métier meilleure et plus rapide. » L’analyste Dan Kirsch affirme que « la transformation de la culture et des processus est au cœur de l’agile comme du DevOps. La technologie ne peut que soutenir ces changements. »

L’agile vous a-t-il obligé à transformer la culture de l’IT et celle de l’entreprise dans son ensemble ?

L’ancien DSI Tim McBreen explique : « l’agile a obligé le personnel à se perfectionner pour pouvoir s’adapter à la culture des sprints et à l’évolution des processus. La culture de l’entreprise a été sous le choc en passant de livraisons tous les 12 à 18 mois à des cycles de livraison de 12 semaines. Il a fallu accélérer les processus et la formation côté métier. Les programmes marketing ont gagné en vitesse. »

En matière de culture d’entreprise, Francis a déclaré que les parties prenantes métier « avaient simplement besoin de vivre cette victoire rapide une première fois ; ensuite, c’est comme si le changement culturel s’opérait de lui-même ! » Cela dit, Young insiste : « l’agile n’est pas le moteur. Les moteurs sont l’hyperaccélération, l’orientation client et l’attention portée aux collaborateurs. Ce sont eux qui font de l’agile une meilleure manière de livrer plus vite et mieux ce qui compte le plus. Le DSI doit influer sur des concepts clés, notamment la livraison itérative et priorisée par petits incréments, plutôt que selon des cycles longs. Cela exige des rôles et des modèles de gouvernance différents. Cela nécessite de déléguer et de soutenir les équipes agiles. »

Veiller à consigner les enseignements tout au long du processus

Les DSI sont formelles : l’agile exige une culture de l’apprentissage. Sacolick explique que « l’agile est un excellent nom. Qui ne veut pas être agile ? C’est mieux que d’essayer d’expliquer au PDG ITIL, DevOps, SRE et autres termes techniques à la mode. Mais les pratiques agiles nécessaires à la transformation et au changement culturel ont une réelle profondeur. Les sprints et les réunions quotidiennes ne sont que les bases. »

Sacolick poursuit : « l’agile relève de la responsabilité des dirigeants. Ceux-ci doivent recueillir les enseignements des rétrospectives, les retours des clients et des utilisateurs finaux, ainsi que les données issues des opérations. Ils peuvent ainsi décider des mesures à prendre. »

Francis est du même avis : « l’IT s’est emparée d’un mot à la mode et lui a donné une allure tendance. Je pense que les entreprises performantes sont plus agiles qu’elles ne le pensent. Elles agissent au lieu de faire du battage. » Kirsch abonde dans le sens de Francis : « l’agile consiste à tirer les leçons des expériences, ce qui est essentiel dans les stratégies visant à échouer vite. Il ne s’agit pas d’échouer, mais d’itérer en permanence et d’apprendre de ses erreurs. »

Steve Jones, Chief Data Architect, ajoute : « la transparence et la consignation des enseignements sont essentielles. Les enseignements négatifs sont souvent les plus précieux. Faire quelque chose de travers n’est pas un problème. Le problème, c’est d’être la deuxième équipe à le faire. »

Avec l’agile, est-il plus facile d’arrêter un projet voué à l’échec ?

Sacolick explique : « le modèle en cascade était loin d’être parfait, même dans un monde où les changements étaient lents. L’exécution des projets en cascade était désastreuse. Tout ce qu’il faisait, c’était fournir des postes de commandement et de contrôle et promouvoir cette culture. Les changements de direction, les arrêts et l’accélération font tous partie de l’agile lorsque la vision et les critères de réussite sont définis en amont et que des boucles de rétroaction honnêtes sont en place. Tout est question d’expérimentation, mais il reste difficile de gérer les émotions liées aux changements de direction et aux arrêts. »

Young estime que les avantages de l’agile incluent le fait que « les fonctionnalités indésirables et les technologies qui ne fonctionnent pas sont identifiées beaucoup plus tôt et ont moins de chances de se retrouver dans les produits mis en production. Si la priorisation est correctement effectuée, le risque d’échec est réduit, car les éléments indésirables, inutiles ou défectueux n’entrent pas dans les sprints et n’en sortent pas. Les échecs de projets ne surviennent pas non plus en général lorsque l’agile est correctement appliqué. En d’autres termes, il faut une priorisation efficace, suffisamment de ressources et des équipes qui bénéficient d’un soutien. »

McBreen ajoute : « pour moi, les éléments clés sont les changements constants et continus des priorités métier. En adoptant une approche agile, nous déplaçons rapidement l’attention vers d’autres domaines. Cela nous permet d’arrêter les itérations lorsque l’entreprise estime que nous en avons fait suffisamment sur les éléments indispensables. L’agile est nécessaire comme approche organisationnelle et culturelle pour tout ce que fait l’IT, qu’il s’agisse d’un projet de développement, du passage à un nouveau fournisseur de services ou de toute autre activité intermédiaire. »

Baurer ajoute : « il semblerait qu’arrêter un projet en échec soit plus facile avec l’agile qu’avec le modèle en cascade, puisque de la valeur est livrée à chaque itération. Toutefois, les projets échouent généralement parce que les priorités métier changent. » Mais Jones apporte une précision importante : « les projets en cascade échouent à la fin ; les projets agiles peuvent échouer au cours d’une itération. Avec l’agile, les occasions de se rendre compte que tout a terriblement mal tourné et d’arrêter le projet sont plus nombreuses. » C’est pourquoi le DSI Anthony McMahon affirme qu’« il est nettement plus facile de réorienter un projet pour éviter l’échec. »

Développer un état d’esprit agile ?

Alors, comment amener l’ensemble de l’équipe à adopter un état d’esprit agile ? Young estime que les dirigeants devraient « commencer avec 1 ou 2 équipes et de bons coachs agiles, capables d’identifier la meilleure structure et la meilleure approche. Faites démarrer ces équipes et amenez-les à livrer. Une fois cela fait, étendez l’approche à davantage d’équipes. Les DSI devraient appliquer l’agile et, avec de très bons résultats, le déployer plus largement. » Bauer est d’accord : « commencez modestement, formez quelques parties prenantes et groupes, puis déployez la démarche auprès d’un public plus large une fois que vous disposez d’un concept opérationnel. »

Sacolick ajoute que les organisations agiles peuvent avoir besoin d’aide en matière « d’automatisation DevOps – CI/CD, IaC et surtout tests continus et AIOps – afin de simplifier les contrôles des changements et de se débarrasser du CAB. La collaboration avec les parties prenantes est souvent négligée dans l’agile, notamment dans les programmes d’innovation. La gestion des produits doit écouter les marchés et les clients, tout en étant encadrée par les parties prenantes. L’agile ne consiste pas à agréger la liste de souhaits de chacun. » Jones conclut : « lorsqu’il est correctement appliqué, l’agile empêche les organisations de rester de simples parties prenantes et les transforme en propriétaires. »

Transformer l’IT

L’agile vise clairement à transformer les organisations informatiques et les entreprises qu’elles servent. Pour réussir, les DSI ont besoin du soutien de l’ensemble de l’entreprise. C’est essentiel pour établir une entreprise capable de se transformer. Sinon, le processus est beaucoup plus difficile et l’organisation risque de provoquer précisément les perturbations décrites par K. Gardner et Alia Crocker.