Soyez agile qu’ils disaient !

2

Plébiscitée par tant de manageurs, la méthode agile serait le remède à tous les maux des entreprises. Mais cette méthode miracle peut-elle réellement fonctionner dans toutes les organisations ?

Par Sébastien Bourguignon

Vous avez sûrement déjà entendu votre patron vous demander sur un mode incantatoire « Soyez agile ! ».
Comme s’il s’agissait de le dire pour le devenir, comme si le mot magique « agilité » pouvait à lui seul transformer les organisations, faire disparaître la lourdeur des processus, permettre aux personnes de collaborer, de casser les silos, d’avoir un meilleur « time-to-market ». Bref l’agilité serait le remède miracle aux maux des entreprises. Cette croyance est ancrée profondément dans la tête des managers, ainsi il suffirait de prendre un livre qui s’appellerait « L’agilité pour les nuls » ou « Scrum expliqué à ma mère » pour régler tous les problèmes de nos organisations. Mais, parce qu’il y a toujours un « mais », ces mêmes organisations démontrent systématiquement leur incapacité à appliquer les bonnes pratiques des méthodes agiles. Entre résistance au changement, manque de courage managérial, contraintes réglementaires, mode de pensée du passé, toutes les bonnes raisons existent pour justifier au bout du compte de l’impossibilité de passer à l’agile, c’est en tout cas ce que je constate régulièrement.

Bien plus qu’une méthode, l’agilité est avant tout un état d’esprit

Elle induit une posture particulière de la part des personnes qui la pratiquent, un changement d’approche et une dynamique collaborative. Autant dire qu’elle est difficilement compatible dans un environnement dans lequel jeux de pouvoir et jeux politiques sont légions, dans lequel la collaboration se cantonne à se faire des allers-retours sur un document par mails ou au travers du réseau social d’entreprise. L’agilité ce ne sont pas des personnes qui font une réunion tous les matins devant un mur couvert de post-it, ce n’est pas non plus le fait de tapisser les murs de l’entreprise avec des « boards Kanban de management visuel » ou bien même le fait de faire un bilan de fin de projet. Et puis l’agilité, ce n’est surtout pas la méthode des start-ups ; les méthodes agiles existent depuis la fin des années 90, les bases ont été posées en 2001 suite à un constat simple : 91% des projets informatiques étaient un échec. Vous l’aurez compris, lorsqu’on parle agilité, on tombe facilement dans les clichés, or à l’ère du numérique et des enjeux de transformation des entreprises, on ne peut plus se permettre de s’arrêter aux images d’Epinal. L’agilité c’est avant tout une équipe projet resserrée, autonome, responsable et pluridisciplinaire, de préférence co-localisée. Elle doit avoir les coudées franches pour pouvoir avancer sans contrainte dans un environnement lui permettant de le faire et lui en donnant les moyens.

L’agilité est-elle une méthode pour toutes les organisations ? Réponse NON

Elle n’est adaptée qu’aux contextes dans lesquels les leviers de transformation sont maximums : soutien inconditionnel du top management, modification profonde de l’organisation, passage d’une vision projet à une vision produit, responsabilisation des équipes, formations, gestion du changement, coaching, recrutement de talents, voilà autant de facteurs clés de succès pour accélérer la transformation numérique des entreprises. Si l’agilité est un prétexte pour communiquer en externe sur vos méthodes de travail, restez comme vous êtes aujourd’hui, dites que vous êtes agiles, mettez des post-it partout, faites des projets dans lesquels vos collaborateurs continueront à se battre contre le système. Si vous voulez être agiles, transformez-vous, prenez le sujet à bras le corps, investissez, ah et arrêtez de chercher un « retour sur investissement » ! Si vous voulez être plus agiles, ce n’est pas pour faire des économies mais pour aller plus vite que vos concurrents et parce que vous savez pertinemment que votre manière de faire actuelle ne fonctionne plus.

Il existe un adage un peu « tarte à la crème » dans le monde de l’IT, il s’agit de la loi de Conway, elle dit que « Tout logiciel reflète l’organisation qui l’a créée. » Alors si sortir un projet informatique dans votre organisation est quelque chose qui est douloureux, ou que votre système d’information est devenu un frein à votre développement et à votre transformation, dites-vous que vous en avez l’entière responsabilité. De la même manière, si vous voulez que tout cela change, cela ne tient qu’à vous, vous en avez là aussi l’entière responsabilité. Donnez les moyens, soutenez vos collaborateurs, révolutionnez votre organisation ET vos processus, et vous avez là les ingrédients pour une transformation agile réussie.

Le coup de cœur de Sébastien Bourguignon
La transformation radicale d’AXA !

Sébastien Bourguignon

Sébastien Bourguignon est manager au sein d’un cabinet de conseil en IT. Il est passionné par le numérique, l’innovation et les start-ups et a créé un blog pour y partager l’actualité autour de ces thématiques. Par ailleurs, il a développé le projet #PortraitDeStartuper dans lequel il fait intervenir des startupers qui présentent leur retour d’expérience dans leur aventure entrepreneuriale. Il est auteur du livre blanc « #80PortraitDeStartuper » et du livre « Portrait de startupers – édition 2017 » paru aux édition Maxima. Enfin, il publie régulièrement de nombreux articles sur Le Cercle Les Echos, Siècle Digital ou encore Le Journal Du Net.

Twitter : @sebbourguignon.

2 commentaires

  1. Excellent article.
    Parfois, le résultat d’un audit met en évidence cette situation où certains « font de l’agile » tout en en étant pourtant très loin du compte.
    C’est comme si la scène de théâtre est en place avec son décors, que les acteurs jouent les scènes, que le public peut observer alors que l’esprit de l’auteur n’est pas du tout respecté.

  2. Bonjour,

    De la méthode Agile, il finit par la méthode Apierre …

    Donc = gravé dans le marbre …. LOL !!!!

    Mais on peut faire de l’agile à pierre …

    je n’ai jamais vu une méthode pouvant s’appliquer stricto sen-sus ….

    Et de mon REX, avec plus de 30 ans de projets divers et variés, j’ai peu de dérapage …

    Exemple du dernier projet, mon cahier des charges identifiait 237 jours et consommés 235 jours ???

    Il faut donc revenir au début dans les premières phases de lancements, DSBE (dossier spécifique des besoins exprimés) études de faisabilités, études de cadrages, réalisation du cahier des charges.

    Dans cette façon de faire la méthode Agile est inadaptée, on revient à la méthode Apierre, qui peut lors de sa mise en place devenir agile.

    Hervé

Réagissez !

Votre adresse email ne sera pas publiée.

Vérification de sécurité * Le temps imparti est dépassé. Merci de recharger le CAPTCHA.