Et si nous retrouvions l’agilité, la vraie ?

Pour prendre du recul, et essayer dans cet article de vous faire comprendre ce qu’est réellement l’agilité, je vais vous parler de deux hommes aux personnalités très différentes. Deux hommes qui n’ont jamais évoqué le terme agilité, et pourtant pratiquaient une vraie agilité au quotidien, chacun à sa manière.

Ces deux hommes ne se connaissent pas, ils ont juste en commun d’avoir travaillé avec moi environ 5 ans.

Ils ont aussi en commun d’être tous deux à la retraite, l’un depuis plus de 10 ans, le second plus récemment.

Comme je ne leur ai pas demandé leur avis pour parler d’eux, je vais respecter leur anonymat, en les appelant Francis A. et Éric L..

Attention, ce ne sont pas des surhommes, des boulettes ils en ont commis, comme tout le monde. Mais en brossant ces deux portraits, je veux vous montrer qu’il y a d’autres manières de travailler, pragmatiques, efficaces, agiles, loin des positions dogmatiques en vogue actuellement.

1. Francis A.

1.1 Le contexte

J’ai rencontré Francis pendant mon premier job, en 1991 (je venais de finir mes études, j’avais 22 ans).

J’étais programmeur débutant et Francis a été mon tout premier CP (Chef de Projet). Je travaillais, sous sa direction, au développement d’un logiciel de gestion pour sociétés de HLM.

Si dans les années 90, vous avez été locataire HLM dans des villes comme Tours, Châlons-en-Champagne, Poitiers, Niort ou Pau, alors vous avez peut-être reçu des quittances de loyer émises par notre logiciel.

Francis avait un peu plus de 40 ans quand je l’ai connu. Il semblait sympa, mais un peu taciturne au premier abord… en fait, je crois qu’il m’intimidait. C’était peut-être à cause de sa barbe, soigneusement taillée, qui lui donnait un air d’instituteur.

Au fil du temps, j’ai appris à le connaître un peu mieux. Au bureau, il était assez secret, nos échanges y étaient exclusivement professionnels, mais lorsque je l’accompagnais en clientèle - ce qui n’arrivait pas souvent – il se livrait un peu.

Pour vous donner une idée plus précise du contexte, nous développions notre logiciel de gestion sur des serveurs propriétaires de la marque IBM, avec l’aide d’un AGL (Atelier de Génie Logiciel), un outil qui correspondrait plus ou moins à certains de nos frameworks d’aujourd’hui. Les outils de type AGL étaient à la mode à l’époque, et de fait, celui qu’on utilisait était vraiment pas mal.

1.2 L’homme et sa méthode

Francis s’efforçait d’utiliser au maximum les possibilités offertes par l’AGL. Cet outil contenait une fonction de prototypage pour élaborer les écrans et les états (éditions). Francis l’utilisait dans les phases d’analyse, ainsi qu’une fonction permettant de gérer la documentation utilisateur associée à chaque écran. Il consignait dans cette documentation le rôle de chacune des données présentes sur les écrans.

Durant les phases d’élaboration des fonctionnalités du logiciel, Francis procédait par itérations successives, envoyant régulièrement au client les nouvelles versions de maquettes (et les documentations utilisateur associées), et il tenait compte des remarques en retour pour corriger le tir, si nécessaire.

Quand le client répondait positivement à une nouvelle proposition, Francis préparait la base destinée à stocker les données correspondant aux nouveaux écrans ou états. Dit en jargon plus technique : il préparait les tables SQL.

Ensuite, Francis me confiait le nouveau lot de maquettes, et c’était à moi de jouer… pour pondre le code mettant tout ça en musique. En me basant sur les maquettes, sur la documentation utilisateur, et sur les tables SQL sous-jacentes, j’avais généralement tous les éléments pour développer. Sauf dans certains cas spécifiques, où un éclairage plus technique était nécessaire, auquel cas Francis prenait soin de me l’expliquer. Et je dois dire qu’il était très bon pédagogue. À noter que Francis me fichait une paix royale pendant que je développais.

Si j’avais besoin d’un renseignement, Francis était généralement très disponible. Il faut dire qu’on n’était pas atteint de réunionite aiguë dans cette société. On bossait, c’est tout, et le travail avançait bien.

Au niveau du travail quotidien, je codais bien sûr, mais j’étais aussi en contact direct avec les clients et leurs utilisateurs (comme d’ailleurs beaucoup de développeurs dans cette même société). J’assurais en quelque sort le support de niveau 1, et parfois de niveau 2, sauf quand la question dépassait mes compétences, auquel cas je passais la main à Francis.

Comme au fil du temps, je connaissais de mieux en mieux le logiciel, Francis m’a demandé d’assurer les formations des utilisateurs. J’ai flippé lors de la toute première formation, mais comme ça s’est finalement bien passé... après, j’en redemandais.

Est-ce qu’on avait des bugs ? À l’époque, on ne disposait pas d’un outillage adapté pour écrire des tests unitaires. Notre AGL – une techno propriétaire - ne proposait pas de solution pour traiter ce point-là. Comme j’étais en contact direct avec mes clients (au téléphone ou lors de mes déplacements chez eux), s’ils rencontraient un problème, cela me retombait inévitablement dessus. Comme je n’avais pas envie que cela arrive, j’étais particulièrement vigilant sur les tests. Les cas de figure qui auraient pu nous échapper à Francis et à moi ? Eh bien… ceux qu’on n’aurait pas pensé à écrire sous la forme de tests unitaires, pardi !

On a bien rencontré quelques problèmes en production, mais principalement des problèmes de performance, qu’on a réglés assez rapidement (notre tout premier client ayant un peu « essuyé les plâtres »).

Pour l’implantation du logiciel dans une nouvelle société, notre workflow était bien rodé :

1. Le client nous transmettait sur bande ou sur disquette les fichiers de données de l’ancienne application à remplacer.
2. J’écrivais les programmes de reprise (d’intégration) des anciennes données vers notre application.
3. On demandait au client de contrôler la qualité des reprises de données.
4. J’allais ensuite former les utilisateurs aux fonctionnalités du logiciel, service par service (gestion locative, comptabilité, contentieux, etc.).
5. On procédait à un test en parallèle des deux systèmes sur un quittancement (le fameux traitement qui génère vos quittances de loyer).
6. Le client vérifiait que le quittancement produit par notre système était bien identique à celui de l’ancienne application.
7. Si tout était OK, le client basculait sur notre système, et se débarrassait de l’ancien.

Délai pour tout ça ? En général, pas plus de 3 mois.

1.3 Ce que j’ai appris avec Francis

Travailler avec Francis m’a permis de découvrir, dans le cadre de mon premier job, une manière de travailler pragmatique et efficace. Il y avait parfois des « coups de bourre », des moments de stress (assez rares), mais ils étaient plus souvent induits par mon inexpérience et ma peur de mal faire les choses, plutôt que par Francis, qui lui gardait son calme en toutes circonstances.

Je me rappellerai toujours le jour où il m’a dit très sérieusement, alors que j’essayais de résoudre un problème dans la précipitation :

« Tu veux aller vite ? Prends ton temps. »

J’ai pu vérifier à de nombreuses reprises, par la suite, qu’il avait mille fois raison.

Lors de mes tout premiers développements pour lui, je me pointais dans son bureau en disant : « j’ai fini ! ». Il testait mes programmes et trouvait des bugs en moins de deux minutes. Je repartais dans mon bureau, tout penaud, devant un Francis goguenard. Piqué au vif, j’ai appris à tester mes programmes et par la suite, il n’arrivait plus à me coincer. Plus tard, j’ai appliqué la même méthode avec mes propres développeurs (c’était à mon tour d’être goguenard, de temps en temps).

Du point de vue de l’agilité, je considère que Francis était très souple. Sa façon de travailler était finalement assez proche de celle d’un Product Owner actuel, mais sans tout le décorum des méthodes agiles. C’était de l’agilité expurgée de tout le superflu : pas de cérémonie, pas de sprint inutile, on prenait le temps qu’il fallait, pour faire les choses bien. Francis a sans doute eu une influence, plus ou moins consciente, sur ma manière d’appréhender le développement, et sur ma manière de me comporter par la suite en tant que chef de projet.

Si j’ai quitté cette société en 1996, c’est pour des raisons personnelles, qui n’ont rien à voir avec Francis, et qui seraient hors sujet ici.

Durant les 3 années qui ont suivi, j’ai occupé des postes d’analyste-programmeur, puis d’analyste. Le travail était parfois intéressant, mais le plus souvent routinier, et je ne retrouvais pas l’autonomie que j’avais à l’époque où je travaillais avec Francis. Pour retrouver une vraie autonomie, je devais passer à la vitesse supérieure, c’est-à-dire passer chef de projet. Et c’est là que j’ai rencontré Éric.

2. Éric L.

2.1 Le contexte

J’ai rencontré Éric L. pendant l’été 1999. Éric venait de prendre ses fonctions de directeur informatique, au sein d’un groupe agroalimentaire.

Au moment de mon recrutement, Éric était en congé dans le sud de la France. Il m’a proposé de venir le rencontrer à mi-parcours, et m’a envoyé un billet de train. Moi venant de Paris, lui venant de son lieu de villégiature dans le Sud, on s’est retrouvé devant la gare de Dijon. Et on a fait notre entretien dans le café d’en face.

En short, bronzé, athlétique, décontracté, Éric avait un peu plus de 40 ans, mais il faisait moins que son âge. C’était une personne au contact facile, agréable. Il semblait direct et dynamique.

Après que je lui ai décrit mon parcours, il a su qu’on allait pouvoir faire affaire, alors il m’a décrit la stratégie qu’il voulait mettre en place.

Pour vous planter le décor, le groupe agroalimentaire était constitué d’une maison mère (normande), dédiée à la production (en l’occurrence, de produits laitiers), et de sociétés de distribution. Ces dernières vendaient des produits laitiers, mais aussi un panel plus large de produits (œufs, légumes, etc.), notamment aux restaurants, aux cantines (la restauration dite « hors foyer »), etc. Dans ces sociétés, le plus souvent issues de rachats, la maison mère avait voulu imposer son propre système informatique, en l’implantant aux forceps. Mais cela s’était mal passé, car le logiciel était vétuste et inadapté aux besoins particuliers de ces sociétés.

Les dirigeants du groupe ayant compris qu’ils avaient commis des erreurs, ils décidèrent de recruter un nouveau directeur informatique, afin de tout remettre à plat. Les implantations de logiciels s’étant vraiment mal passées, Éric héritait d’un service informatique exsangue. Il devait le réorganiser, et vite, car il avait deux gros chantiers en perspective :

• le bug de l’an 2000 : aucune des sociétés du groupe ne pouvait espérer passer le cap sans encombre, tant leurs systèmes informatiques étaient vétustes. Il fallait « patcher » les applications en urgence, pour avoir des dates correctes (passé le 1er janvier 2000), et il ne restait que quelques mois pour le faire. Il y avait 5 sociétés de distribution à « traiter », plus la maison mère ;
• l’euro : le passage à la monnaie unique était fixé par les politiques au 1er janvier 2002. Ce passage aurait impliqué trop de modifications dans les vieux logiciels pourris des sociétés. Éric voulait les débarrasser de leurs logiciels au profit d’une nouvelle solution, plus pérenne, avant le passage à l’euro. Il y avait 5 sociétés à « traiter », et on ne pouvait s’en occuper qu’après avoir « traité » le problème de l’an 2000. En résumé, il fallait remplacer le système informatique des 5 sociétés en 2 ans. Vous voyez le tableau ?

Avec ce qu’Éric venait de m’expliquer, j’ai tout de suite compris que j’allais m’éclater, alors j’ai dit : « banco, je veux en être » (euh, peut être pas exactement en ces termes).

Éric me confiera plus tard :

« Lors de notre première entrevue, j’ai pensé que tu n’avais pas tout à fait les compétences d’un chef de projet, mais j’ai senti que tu avais la capacité à les acquérir... »

Éric avait donc fait un pari sur moi, et dans l’ensemble, je crois qu’il ne l’a pas trop regretté.

Pour compléter le tableau, je dois ajouter qu’Éric recrutait non pas un, mais deux CP. Un CP serait dédié à la maison mère et à la production, le second serait dédié aux sociétés de distribution. C’est moi qui ai pris cette seconde casquette. Éric a recruté aussi un ingénieur système, pour assurer la remise à plat du parc de serveurs disséminés dans les différentes sociétés.

Le passage à l’an 2000 n’a pas été une mince affaire, mais avec une bonne planification, orchestrée par Éric, ça s’est plutôt bien passé.

J’ai troqué quelque temps ma casquette toute neuve de CP pour celle de programmeur, et j’ai pris en charge le « patchage » des programmes d’une de mes 5 sociétés de distribution. D’autres développeurs ont pris en charge d’autres sociétés. Parmi ces développeurs, il y avait mon homologue CP dédié à la production (recruté en même temps que moi), plus quelques développeurs rescapés de l’ancien service informatique... plus quelques prestataires qu’on avait réussi à recruter, non sans peine, tant le marché de l’emploi était tendu à l’époque.

Bref, on a réussi à passer l’an 2000 sans encombre, et c’est à partir du 1er janvier 2000 que j’ai commencé à travailler, avec Éric, sur le chantier consistant à remplacer les logiciels de gestion commerciale des 5 sociétés de distribution. C’est là que j’ai découvert la méthode Éric.

2.2 L’homme et sa méthode

Ingénieur de formation, Éric avait occupé un poste d’analyste-programmeur en début de carrière, puis il avait été consultant plusieurs années pour différents groupes. Il avait participé à l’implantation de progiciels de gestion, et il avait acquis une solide expérience en matière de conseil et de pilotage de projet.

Moi-même, j’avais une solide expérience d’analyste-programmeur, et une expérience toute fraîche d’analyste (acquise sur mon poste précédent). Je rappelle que j’avais participé activement à l’implantation d’un logiciel dans 5 sociétés de HLM. Mais les HLM, c’était assez facile, car les sociétés avaient toutes à peu près les mêmes besoins. De plus, Francis maîtrisait bien le sujet, et balisait la route. Il me manquait donc une partie de la méthodologie nécessaire pour aborder un projet plus difficile comme celui qui nous attendait. Éric allait me l’enseigner.

Éric me proposa la démarche suivante :

• Étape 1 : faire le recensement des besoins des 5 sociétés (pour ça, un audit s’imposait) ;
• Étape 2 : à partir de cet audit, établir un cahier des charges regroupant les besoins de ces 5 sociétés ;
• Étape 3 : muni de notre cahier des charges, rencontrer des éditeurs de progiciels et identifier la perle rare ;
• Étape 4 : piloter, avec l’aide de l’éditeur sélectionné, l’implantation du progiciel dans les 5 sociétés.

On est donc partis, chacun de notre côté, pour démarrer nos audits.

À l’époque, je n’avais pas de localisation géographique clairement définie. Éric me cherchait un bureau dans l’une des filiales parisiennes du groupe. Géographiquement, la filiale qui semblait la plus pratique se trouvait à Paris, près de la porte de Charenton. Problème, les locaux n’étaient pas très accueillants, mais il y avait un bureau vacant, Éric m’a proposé qu’on y fasse un tour.

Le bureau qu’on nous proposait était petit et mal éclairé. Éric a arraché (plus que négocié) un bureau plus grand (lui aussi vacant), donnant côté sud, donc plus lumineux. Il leur a aussi « emprunté » un bureau et des chaises (la pièce étant vide), et on s’est installé en double mode « squat » et « startup ». Éric avait un aplomb incroyable, et un côté très direct, il obtenait à peu près tout ce qu’il voulait, avec le sourire.

Étant donc « installé » dans cette filiale parisienne, j’en ai profité pour démarrer mon premier audit sur place. Éric m’avait fourni des modèles de documents issus de sa période de consultant, pour que l’on ait tous deux la même base de départ, et que l’on puisse produire des documents au rendu homogène.

Bon, j’espère que vous en m’en voudrez pas si j’accélère un peu le rythme...

Fin février, nous avions audité nos 5 sociétés.

Fin mars, nous finalisions notre cahier des charges qui était composé de plusieurs parties : gestion des produits, gestion des fournisseurs, gestion des clients, gestion des commandes, gestion des factures, etc.

À noter qu’Éric travaillait souvent à partir de la maison mère (en Normandie) et moi, depuis ma filiale parisienne d’implantation. On échangeait nos fichiers zippés par mail, à une époque - l’an 2000 - où le haut débit n’existait pas encore. Mais cela se passait bien et on avait acquis rapidement un bon rythme de travail.

Début avril, nous avons commencé à rencontrer des éditeurs. Ils écoutaient nos doléances, nous présentaient leurs solutions, mais à chaque fois, on sentait un malaise. Il y avait quelque chose qu’ils ne voulaient pas nous dire. J’ai compris indirectement, en discutant avec un consultant, dans un salon informatique :

« Oh là... l’agroalimentaire, nous on n’y va pas. Il y a trop de spécificités, c’est trop compliqué. Notamment avec la gestion des stocks, les DLC (Dates Limites de Consommation), les produits à rotation courte. On sait pas vraiment faire. On préfère travailler avec l’industrie, c’est moins compliqué de gérer des stocks de boulons. Et puis dans l’agroalimentaire, ils sont généralement très exigeants, mais aussi très radins... ».

Fort de cette réflexion hautement philosophique, je commençais à penser que l’on ferait mieux de le développer nous-mêmes, ce logiciel de gestion. Mais je n’osais pas en parler à Éric, car je ne savais pas comment il prendrait la chose. Je lui relatais cependant la remarque faite par le consultant lors du salon.

Éric avait senti comme moi le malaise, il me confia qu’il n’était pas convaincu par les présentations des éditeurs qu’on avait rencontrés. Mais je ne m’attendais pas à sa réflexion suivante :

« Et si on le développait nous-mêmes, ce logiciel, ça nous mènerait où ? »

La vache, je ne l’avais pas vu venir, ce coup-là. Joli pivot à 180°... un champion de taekwondo n’aurait pas fait mieux. En tout cas, j’étais très heureux de ce changement de braquet.

Question suivante d’Éric :

« Tu le développerais en quoi, toi, ce logiciel ? »

Pour savoir où le projet pouvait nous mener, nous devions être sûrs de la techno de développement à utiliser. Et le choix de technos était plus restreint qu’aujourd’hui. Sachant que nos 5 filiales étaient équipées du même type de machine IBM sur lesquelles j’avais développé le logiciel pour HLM, et compte tenu du délai ultra-court qui était le nôtre pour développer notre solution, je répondis à Éric que je le ferais volontiers avec l’AGL « truc », que je connaissais bien.

Éric était ouvert à cette idée, alors nous avons repris notre cahier des charges, point par point, en essayant d’estimer le temps de développement de chaque fonctionnalité. À partir de cette estimation « à la louche », on a pu calculer un nombre de jours/hommes, et estimer que si on prenait 2 développeurs, on pourrait développer une première version de notre logiciel en à peu près 9 mois. Cela nous menait à la fin de l’année 2000. Si notre scénario tenait la route, il nous resterait un an pour déployer le logiciel dans les 5 sociétés.

On avait quelques incertitudes sur notre chiffrage, mais on a estimé d’un commun accord que si je prenais en charge le développement de certaines fonctionnalités, en renfort des deux développeurs, ça devait tenir.

On a contacté l’éditeur de l’AGL « truc », on lui a pris des licences de développement et deux développeurs pour 9 mois. Avec son aplomb incroyable (et le sourire), Éric a imposé le tarif, en arguant qu’il ne pouvait pas mettre plus. Ils ont fait un peu la gueule, mais ils étaient trop heureux de récupérer un nouveau client, avec des licences annuelles récurrentes, et de caser deux développeurs en prime, alors ils n’ont pas discuté.

Mon bureau manquait de mobilier pour accueillir les deux prestataires, alors Éric en a piqué encore un peu (toujours avec le sourire) dans les autres bureaux de ma filiale de rattachement.

Comme le câblage informatique était vétuste et inadapté, notre ingénieur système est arrivé un beau matin, de Normandie, avec des rouleaux de câble Ethernet, des stocks de prises RJ45 à sertir, et une drôle de pince dont j’ai oublié le nom. Si on m’avait dit qu’un jour je sertirais des prises RJ45... j’en rigole encore 20 ans après. N’empêche qu’en quelques jours, le câblage réseau de l’entreprise était refait à neuf.

Éric et moi avons travaillé d’arrache-pied pour rédiger les premières SFD (Spécifications Fonctionnelles Détaillées). Il s’agit d’un document décrivant précisément ce que le développeur doit créer. Il doit être le plus précis possible, de manière à ce que le développeur ait toutes les cartes en main. Il y avait une SFD pour la gestion de produits, une autre pour la gestion de tarifs, etc. Ce type de document est long à préparer, mais son gros avantage, c’est qu’il constitue un mémoire de ce qui a été développé. C’est un outil précieux pour préparer les tests, pour la maintenance, et pour la passation de connaissances quand on renouvelle les équipes.

Quand nos deux développeurs sont arrivés, nous leur avons présenté nos premières SFD, avons évalué la charge de développement avec eux pour être sûrs que nous étions en phase, et ils ont attaqué le développement. Pendant ce temps-là, je continuais à rédiger des SFD, Éric aussi, et on se relisait mutuellement pour être sûrs de ne rien oublier. Quand je n’ai plus eu de SFD à rédiger, je me suis attelé au développement de certaines fonctionnalités (comme la gestion de commandes clients).

Nous avons démarré une première société en février 2001, la seconde en juin 2001, la troisième en septembre 2001. Le processus de déploiement était assez proche de celui que je vous ai décrit avec Francis (reprise des données, formations des utilisateurs, etc.).

Rapidement, on s’est rendu compte d’un problème : on aurait tout juste le temps d’installer une 4e société avant le 1er janvier 2002, mais certainement pas une 5e. Alors Éric a missionné une société de services pour « patcher » l’application de la 5e société (avec un convertisseur de devises). De notre côté, nous avons déployé la 4e société en novembre 2001, et comme notre application incluait le « multi-devises », nous avons basculé nos 4 sociétés en euro le 1er janvier 2002. Nous avons pu souffler un peu, avant de nous occuper de la 5e société, quelques mois plus tard. Mais nous n’avons pas soufflé très longtemps.

Car pendant que nous travaillions sur nos 5 sociétés, la maison mère continuait à racheter des sociétés, et rapidement notre portefeuille de sociétés à équiper s’est agrandi. Avec en prime de nouveaux métiers à ajouter à notre logiciel, comme la gestion de la viande, des surgelés, du poisson, et de l’alcool. Temps de déploiement de notre logiciel à ce stade ? De 3 mois pour les sociétés les plus faciles, à 9 mois pour les sociétés ayant des processus métiers plus complexes nécessitant des adaptations. Dès 2002, nous avons remplacé les développeurs prestataires par des développeurs internes recrutés par nos soins. Éric avait aussi beaucoup de travail avec la maison mère, sur la partie production, il avait besoin de dégager du temps pour ça, alors il a recruté un consultant pour me seconder sur les audits et sur l’accompagnement des clients, pendant que je pilotais les nouveaux développements.

J’aurais encore beaucoup de choses à raconter, mais elles ne vous apprendraient rien de plus sur la méthode Éric. Et l’article serait trop long pour pouvoir être publié dans mon magazine préféré. Retenez juste que nous avons installé notre logiciel dans 11 sociétés en à peu près 5 ans. Pour des gens qui n’utilisaient pas de méthodes dites agiles, c’est pas mal non ?

Je peux juste ajouter que, le groupe de filiales s’étant agrandi, il s’est restructuré. Éric s’est complètement recentré sur le pilotage de l’informatique de la maison mère, et donc de la production. Un directeur informatique a été recruté spécialement pour les filiales, mais il n’avait pas les qualités humaines et managériales d’Éric, et pas non plus le même point de vue. Comme lui et moi n’étions d’accord sur rien, je suis parti. Sans regret. Je considérais que j’avais bouclé un cycle, qu’il était temps pour moi de passer à autre chose, et en particulier de pivoter vers le monde de l’open source.

2.3 Ce que j’ai appris avec Éric

Tout n’était pas rose chez nous, mais je crois pouvoir dire que nos développeurs étaient pour la plupart des développeurs heureux. La lecture des SFD leur permettait d’acquérir de solides connaissances métier. Cela les déchargeait mentalement, ils pouvaient donc se concentrer sur la qualité du code. Ils maîtrisaient leurs délais et pouvaient travailler avec une grande autonomie. Attention, cela ne peut fonctionner que si les SFD sont rédigées de manière claire et rigoureuse.

Avec Éric, on a quand même eu quelques moments de stress, lors des déploiements. Parfois, on s’apercevait un peu tard que les utilisateurs avaient oublié de nous dire des choses (sans doute parce que nous n’avions pas posé toutes les questions qu’il fallait). Parfois, on nous avait sciemment caché des choses (car certaines personnes voulaient faire barrage à l’implantation de notre logiciel). Alors, on a quelques fois fait l’impasse sur les SFD, pour passer en mode « hyper-agile ». Nous en étions capables, car nous sprintions seulement quand c’était nécessaire, pas en permanence (le reste du temps, on se posait et on prenait le temps de réfléchir). Dans les moments de stress, la petite phrase de Francis (« tu veux aller vite, prends ton temps ») trottait dans ma tête et me servait de garde-fou. Merci à toi, Francis.

J’ai appris, grâce à Éric, qu’il ne faut jamais douter de ses capacités, qu’il faut aller de l’avant. J’ai été aux premières loges pour observer avec quel brio il gérait la complexité et contournait les difficultés. En termes d’agilité, Éric était une vraie machine de guerre.

Nous avons parfois eu quelques accrochages, Éric et moi, car en tant que DI, il était soumis à de fortes contraintes budgétaires, qui l’amenaient parfois à prendre des décisions que je trouvais arbitraires. Mais après discussion, nous trouvions toujours un terrain d’entente, car notre priorité à tous deux était de fournir une bonne qualité de service aux utilisateurs.

Je dois d’ailleurs dire un mot des utilisateurs. Que ce soit dans les sociétés HLM, comme plus tard dans les sociétés de distribution agroalimentaires, j’ai eu la chance de rencontrer des personnes formidables, à l’écoute, ravies de pouvoir m’expliquer leur métier. Ces personnes m’ont beaucoup appris, elles aussi, je leur voue une reconnaissance éternelle.

Conclusion

Les méthodes agiles ont sans doute de bons côtés, mais elles sont appliquées de manière systématique, et dogmatique, sur de nombreux domaines, où elles me semblent moins pertinentes que d’autres approches. C’est un très gros problème, et je ne suis pas le seul à le penser.

Si vous lisez la page de Wikipédia consacrée à ce sujet [1], vous verrez que plusieurs chefs de file à l’origine du mouvement « agile » s’en sont désolidarisés, pour diverses raisons.

Dans un manifeste publié tout récemment [2], Ryan Singer (un des leaders du projet Basecamp) écrit ceci :

« People in our industry think they stopped doing waterfall and switched to agile. In reality they just switched to high-frequency waterfall. »

Dans une conférence que je vous recommande vivement [3], Romeu Moura explique que les grandes boîtes sont de petits panoptiques, et que les coachs agiles sont les nouveaux jésuites. Je suis assez d’accord, mais je pense qu’il n’y a pas que les grandes boîtes qui sont touchées par le phénomène.

L’agilité, la vraie, s’inscrit dans la manière dont vous réagissez aux difficultés, et dans votre manière de sortir des cadres imposés. Si vous êtes capables de sprinter quand c’est nécessaire, et de décélérer le reste du temps, alors vous êtes vraiment agiles.

Si vous cherchez des repères, la vraie agilité se trouve probablement quelque part entre la méthodologie de Francis et celle d’Éric. À vous de bien placer le curseur, sachant que vous pouvez le réajuster au cas par cas.

Bon courage à vous. Portez-vous bien.

Références

[1] Définition de « méthode agile » sur Wikipédia : https://fr.wikipedia.org/wiki/M%C3%A9thode_agile

[2] Le livre « Shape Up: Stop Running in Circles and Ship Work That Matters » : https://basecamp.com/shapeup

[3] Conférence de Romeu Moura : https://www.youtube.com/watch?v=Cj_1qEaa_Wc