Le Leadership informatique agile #

La nouvelle plateforme collaborative interne a été livrée. C’est le résultat de plusieurs années de travail. Cela inclut des cahiers des charges, la planification, des rapports, et l’écriture de politiques de sécurité internes. Les équipes de développement ont aussi beaucoup contribué. Elles ont fait des tests et des configurations. Mais maintenant, le jour J est enfin arrivé. Le produit est entre les mains des utilisateurs et…. Ça ne donne pas la valeur attendue. Personne ne l’utilise et tout le monde se plaint du manque de fonctionnalités de base.

Tous les contributeurs sont statisfaits et blâment une autre équipe.

C’est pour ce genre de problème que les méthodes agiles sont apparues. Elles ont d’abord été utilisées en informatique, puis se sont étendues à d’autres domaines.

La gestion du risque par le contrôle #

Tout projet informatique est complexe et comporte de nombreux risques souvent durs à évaluer. Pour ajouter à cela, la plupart du temps, on ne sait pas exactement ce que l’on veut, on ne connait pas bien l’impact de la création ou le remplacement d’un outil, il faut envisager les problèmes de sécurité, de règlementations… Bien sûr, nous ne savons pas ce que l’avenir nous réserve. Entre le début d’un projet et sa fin, tout peut changer. Cela est particulièrement vrai aujourd’hui, où chaque mois, un nouveau produit IA est lancé.

Dans le passé, les départements informatique des entreprises géraient les incertitudes et les risques avec du contrôle. Ils définissaient des cahiers des charges très précis. Ensuite, ils faisaient un plan de développement détaillé. Ils rédigeaient aussi des politiques claires sur ce qui était faisable ou non. Ils ont aussi établi des validations et des étapes claires de go/no-go. Cela se passe avant que le projet n’atteigne l’utilisateur final.

En contrôlant tous les aspects d’un projet, on veut limiter les risques.

Ce modèle s’applique à l’ensemble de l’entreprise. Martha Heller dit dans “The CIO Paradox” : “La plus grande qualité d’un Directeur des Systèmes d’Information est la patience. Il doit savoir modérer le désir d’aller vite pour s’assurer que tout est bien en place.”

Alors, les directions interprètent leur manière d’“ajouter de la valeur”. Elles imposent que toutes les solutions suivent une architecture déjà définie et acceptée. Elles retardent la livraison aux utilisateurs pour s’assurer que toutes les politiques sont validées. Elles bloquent les initiatives via ses politiques concernant le lancement d’un nouveau projet.

En résumé, la direction informatique passe plus de temps à prouver la qualité de son travail qu’à apporter de la valeur aux utilisateurs.

Combien de projets IT dont tous les indicateurs étaient au vert n’ont servi à rien ? (selon une étude de Microsoft, c’est environ un tiers des idées qui améliorent la métrique qu’elles pensent améliorer).

Les barbares agiles #

La révolution agile n’est pas juste des outils tendance comme SCRUM. Ce ne sont pas non plus des technologies comme l’intégration continue. Elle permet de livrer des mises à jour en continu. Ce n’est pas non plus le DevOps, qui rapproche des fonctions historiques. Tout cela résulte d’un changement complet dans la gestion du risque.

L’agilité, c’est gérer le risque par la réactivité et l’auto-correction.

Ce changement de point de vue est barbare pour la plupart des DSI. Au lieu de tout gérer pour que tout soit parfait, le développeur agile se prépare à réagir vite en cas de problème.

Les créateurs de la méthode SCRUM présentent cela sous forme d’une équipe et d’un “product owner” :

Le product owner décide le quoi (ce que l’équipe doit faire).
L’équipe décide le comment (quels outils ou technologies on va utiliser).
Personne n’est autorisé à faire de l’ingérence a propos de ces choix.

C’est ici que les barbares de l’agile se heurtent aux habitudes du leader informatique qui aime le contrôle. L’équipe peut utiliser une nouvelle technologie et la mettre en production. On peut aussi s’éloigner du cahier des charges pour mieux répondre aux besoins du product owner. Il est possible d’avoir un code de “moins bonne qualité” si cela rend l’application plus efficace. De plus, on va discuter avec le client au lieu de simplement lire les demandes dans le contrat.

Les équipes agiles ont travaillé dur pour s’affranchir de la gouvernance informatique traditionnelle. Elles ont pris le contrôle de l’infrastructure avec le mouvement DevOps, c’est a dire gérer elles même l’architecture, sans intermédiaire. Cela leur a permis d’être plus rapides et flexibles lors des mises à jour. Elles échangent directement sur les besoins. Pas besoin de passer par la direction pour un cahier des charges. Elles ont aussi automatisé le suivi et les retours. Cela permet de corriger les écarts sans attendre un retour externe.

C’est bien pour cela que l’agilité va au delà des outils et des méthodologies à la mode :

Si vous bloquez votre application pendant 2h pour faire une mise a jour, vous pouvez utiliser des outils labélisés “DevOps”, vous n’avez pas une approche qui permet de faire des dizaines de modifications par jour.
Si vous livrez une mise a jour de votre application tous les 3 mois en blocs, vous pouvez faire des “sprints” ça ne reste pas une méthodologie agile.

Alors aujourd’hui, il n’est pas aberrant de se demander quel est le rôle du leader dans une organisation agile. Si les équipes s’organisent et travaillent directement avec le client, pourquoi avoir un management ?

La fin du département informatique. #

On voit souvent le rôle de Directeur des Systèmes d’Information comme le pont entre les équipes informatique et les besoins de l’entreprise. C’est un peu comme si l’IT était un sous-traitant. D’un côté, il y a l’entreprise avec ses besoins et sa valeur. De l’autre, il y a les nerds en tee-shirt, experts en informatique, mais souvent déconnectés des besoins réels. Cette vision fonctionne bien pour tout ce qui est transactionnel. Par exemple le support client, la gestion des ordinateurs, les mises à jour et la maintenance. Dans ces domaines, il est facile de contrôler le temps et les coûts. C’est aussi simple de comparer avec la concurrence.

Cette division existe depuis les débuts des ordinateurs et d’internet. D’un côté, il y a ceux qui saisissent le besoin. De l’autre, ceux qui maîtrisent la technologie. Elle semble étrange dans un temps où, jour après jour, chaque tâche de l’entreprise se fait avec un ordinateur. Aujourd’hui, plus les gens aiment la technologie, moins ils apprécient leur DSI. Dans les années 80, l’IT offrait des solutions. Mais petit à petit, l’IT est devenu une source de complexité et de barrières. Aujourd’hui, il est courant d’avoir de meilleures technologies à la maison qu’au travail. Cela aurait été impensable il y a quelques décennies. Et justement, est-ce vraiment souhaitable ?

Nous n’avons pas aujourd’hui de département “téléphonie” pour la stratégie téléphonique. Il n’y a pas de département pour le papier et le stylo, ni pour l’électricité. Tout cela est devenu normal, opérationnel et quotidien. Il est probable que dans le futur, décrire combien une entreprise dépense en informatique n’aura aucun sens. Tout sera inclus dans chaque produit et dans chaque budget comme les autres formes de dépenses et coûts.

Dans les entreprises les plus efficaces aujourd’hui, ceux qui conçoivent, fabriquent et maintiennent les produit basés sur des solutions numériques font partie prenante des opérations, ils ont pleine charge et responsabilité de la satisfaction client. Le département informatique poste de coût n’existe plus, il est indissociable de la création de valeur.

Provoquer et Observer #

Dans un monde où les équipes s’auto-gèrent et où le département informatique n’existe plus, quel est le rôle du leader informatique?

Le leader informatique agile doit d’abord promouvoir l’agilité dans l’organisation. Il doit aussi briser les barrières entre la technologie et les opérations. L’agilité nécessite un entretien constant. Le désir de contrôle est fort, car il rassure. C’est au leadership de veiller à ce que l’agilité reste toujours là. C’est aussi son rôle d’introduire l’agilité dans des équipes qui ne l’ont jamais expérimentée. Il doit s’occuper des inquiétudes et ajuster ces méthodologies selon les besoins. Les principes de base de l’ Agile Manifesto sont communs. Cependant, la méthodologie varie selon les environnements. Dans des milieux très régulés, elle diffère de ceux plus flexibles. Mais ne croyez pas qu’il vous concerne pas, même l’armée a adopté l’agilité pour ses équipes, vous pouvez le découvrir dans le livre Teams of Teams.

La base de l’agilité est d’observer et de s’adapter fréquemment plutôt que de suivre un plan aveuglément. C’est-à-dire valoriser le fait d’apprendre et d’essayer plutôt que de le limiter et de le punir. Le leadership vise à garantir que les équipes adoptent une démarche agile. Cela peut passer par des processus, de la technologie, ou d’autres moyens. L’objectif est toujours de maximiser la valeur pour le client.

Le leadership va s’assurer que les initiatives commencent et se déroulent bien. Voici quelques questions à poser pour vérifier si une initiative peut bien commencer :

Quels sont les résultats effectifs que l’équipe cherche à obtenir ? Pourquoi ces résultats sont-ils importants pour l’entreprise ? – S’assurer que l’équipe a une bonne vision et est alignée sur la stratégie.
Comment l’équipe veut définir les besoins et fonctionnalités qu’elle doit développer ? - S’assurer non pas que les besoins sont bons (ça c’est leur problème en autonomie) mais que leur manière de décider du bienfondé d’un développement est bonne.
Comment l’équipe va travailler ensemble? Quelles sont les compétences? Conment elles vont procéder pour faire de l’amélioration continue? - Faire en sorte que l’équipe collabore, apprenne ensemble et s’engage à s’améliorer en continu.
Comment l’équipe compte avoir du feedback sur son travail par le management? A quelle fréquence ? - Veiller à ce que le feedback des managers soit pris en compte dans le fonctionnement.
Quels sont les principaux risques ? Comment l’équipe va-t-elle rapidement tester ces risques et gagner de l’information ? - Comprendre comment ils comptent apprendre et gérer, en itérations permanentes, les imprévus.
Comment puis-je les aider à accomplir leurs objectifs ? - S’assurer que l’on ne les empêche pas.

La différence, c’est qu’au lieu de vérifier chaque étape du plan, on s’assure que l’équipe est bien préparée. Cela lui permet d’atteindre ses ambitions et de s’adapter quand ses hypothèses évoluent. Au lieu de choisir des solutions concrètes pour l’équipe, assurez-vous qu’ils ont tout ce dont ils ont besoin. Cela les aidera à prendre de bonnes décisions lorsque des imprévus se présenteront.

Amélioration continue du leader #

Le leadership agile n’est pas facile. Comme toute tâche en entreprise, il doit s’améliorer en continu. Le leader doit aussi avancer par petites étapes. Il a besoin de retours constants. Il doit se remettre en question. Cela l’aide à mieux répondre aux besoins de l’entreprise.

Il n’y a pas de raisons que l’agitilité soit limitée aux équipes, le leadership aussi doit faire preuve d’amélioration continue.