Accueil > Divers > Il faut en finir avec l’agilité « romantique »

Il faut en finir avec l’agilité « romantique »

Marie et Hervé viennent d’acheter une maison de caractère dans un petit village de Normandie. Ils sont très fiers de leur acquisition, bien que l’aventure soit loin d’être finie : il y a encore de gros travaux à faire. Parmi les changements qui préoccupent le couple, il y a une grosse dizaine de fenêtres à changer : vieilles de plus de quarante ans, en vitrage simple, elles accusent sérieusement leur âge. En fait, en grattant un peu, Hervé s’est aperçu qu’elles s’effilochaient à l’ongle. Le doute n’est pas permis : il faut tout changer. Heureusement, au sein même du village travaille Marc. Marc est maçon. Et un maçon très réputé, capable très largement de sortir de son cœur de métier – le béton – pour faire toutes sortes de travaux. Changer une fenêtre : il sait faire. Intéressés, Hervé et Marie consentent à lui confier ce chantier-là aussi. C’est plus simple de s’adresser au même artisan. Si Marc est si compétent, c’est que c’est un passionné. Il a construit sa maison de ses mains et refait bien des habitations du village. D’ailleurs, le village, c’est un peu sa chose : il y est né, il l’a restauré, il l’a embelli, il est en très fier. D’ailleurs, Marc est fier. Seulement voilà, Hervé a posé une condition inacceptable : les fenêtres devront être refaites en PVC. C’est pratique, c’est moins cher, c’est plus simple. Marc est atterré. Dans un village dont l’origine se perd aux temps des Plantagenets, le PVC, ça fait tâche. Marc fait son travail : il conseille Hervé et Marie. On peut faire, dit-il, de très belles ouvertures en chêne. Avec les traitements actuels, elles tiendront bien encore cent ans. Hervé et Marie écoutent attentivement, mais cabrent sur le prix. Il est double. Hervé et Marie ont un budget qui n’est pas extensible et clairement, les fenêtres en chêne n’entrent pas dans leurs priorités. Donc ce sera du PVC. A moins que Marc puisse les faire au même prix. Très déçu, mortifié même, Marc a presque failli accepter. Mais ce serait perdre deux milliers d’euros : un mois de salaire. Une fois seul dans son chantier, Marc rumine. Il a bien essayé d’expliquer encore et encore au couple que le PVC est une erreur : rien n’y a fait. Les fenêtres en chêne, c’est non et re-non. Mais voilà, Hervé et Marie sont retournés à Paris, et Marc est, pour un bon mois, le seul maître à bord. Alors Marc prend la décision de décider à la place d’Hervé et Marie : « Dès qu’ils verront les fenêtres en chêne dans la belle maison superbement restaurée, ils comprendront leur erreur et applaudiront ! » Marc en est certain : n’est-il pas l’homme de l’art ? Ne sait-il pas cent fois mieux ce qu’il convient de faire ? En plus, lui, est normand. Marc a monté les fenêtres en chêne, sans bien sûr en avertir Hervé et Marie. Hélas, cela a pris un peu plus de temps que prévu – le Lapeyre du coin n’avait pas les articles en stock – et le chantier ne pourra pas être fini à temps. Presque,  mais pas tout à fait. C’est tout de même de la belle ouvrage. Le week-end suivant, Hervé et Marie viennent visiter leur future demeure. Au premier coup d’œil, ils sont ravis. Un peu étonné tout de même que les finitions ne soient pas faites et qu’ils ne pourront donc pas passer leur première nuit dans leur nouveaux « chez eux ». Leur étonnement grandit lorsque Marc leur présente les premières factures. Et Marie a tôt fait de remarquer que les fenêtres sont de chêne et le prix aussi. Marc a beau se défendre et démontrer, rien ne vient calmer la fureur d’Hervé. Le ton monte aussitôt et les noms d’oiseaux fusent. La rage d’Hervé est spectaculaire : en moins de dix minutes, le parisien a perdu toute la confiance qu’il avait dans le normand. Non, il ne paiera pas les fenêtres en chêne ! Et oui, dès que Marc aura fini ce qui est en cours, on stoppera la relation-là ! Et que Marc s’estime heureux qu’il ne lui fasse pas payer des pénalités de retard ! Marc, bien sûr est outré : il a l’impression qu’Hervé en fait une question de principe et que son beau travail – car il a bien travaillé – n’est absolument pas pris en compte. Les deux hommes se séparent irrémédiablement brouillés. Désormais, ils ne se parleront que par avocat interposés. Et à la fin, c’est Marc qui perd le procès… Qui a raison dans l’affaire ?

C’est Hervé qui a raison.

Pourquoi ? Parce que c’est le CLIENT.

C’est le CLIENT qui paie, donc ’est le CLIENT qui décide. L’artisan propose, conseille, négocie un prix mais à la fin DOIT faire ce que le CLIENT demande. Ou laisser un autre artisan le faire. Ainsi vont les relations commerciales. Et vous, qu’auriez-vous fait à la place d’Hervé ? De Marc ? Mais me direz-vous, pourquoi raconter cette histoire de BTP dans un blog qui traite de développement logiciel ? Eh bien, parce que la métaphore du BTP est merveilleusement compatible avec notre activité de développeurs, où il est question de réalisation à façon, « d’architecture », de « craftmanship » (= artisanat). C’est d’ailleurs une métaphore à laquelle je reviens, chaque fois que sur un projet, il se passe un incident et qu’il faut trouver une solution. Essayez, vous verrez que cela marche très bien :). Si j’ai raconté cette histoire, donc, c’est qu’il m’est fréquent de rencontrer des développeurs qui ont oublié leur professionnalisme en chemin. Ce sont de bons « devs ». Ils ont des convictions. Ils savent que telle ou telle technologie est « innovante » et que telle autre ne l’est pas. Du moins, ils l’affirment face à d’autres « devs », probablement aussi bons et qui affirment le contraire. Les Marc, dans notre métier, sont légions. Hélas. Trop de « devs » exigent de n’en faire qu’à leur tête. Et ils ont trouvé un extraordinaire alibi : l’agilité. L’agilité dit : le « dev » doit être écouté. Certes. Mais écouté, ne veut pas dire obéi. Le product owner, qui est owner du product, n’est-ce pas, doit lui aussi être écouté. Et obéi, lui. Si, si. Les méthodes agiles, ce n’est pas un processus « low cost » dans lequel tout le monde fait ami-ami, où des « product owners », en fait « owner » de rien partagent leur préoccupations avec des « devs » compatissants, à grand rayon d’action, artisans sans engagement (c’est-à-dire ne subissant pas eux-mêmes les conséquences financières de leurs errements) souverains sans partage dès qu’il est question de technologies ou de priorités autre que métier. Et tout ce petit monde de dépenser l’argent du client – l’entreprise qui a commandé le projet – sans que personne ne se soucie vraiment de lui en rendre des comptes précis. Ça,  c’est le TP entre étudiant, le club des passionnés, voire même, la cour de récréation. Ce n’est pas l’agilité. L’agilité, c’est beaucoup plus sérieux. L’agilité c’est Hervé et Marie qui commandent des fenêtres en PVC, c’est Marc qui conseille le chêne, c’est Marie et Hervé qui refusent, c’est Marc qui fait en PVC comme on le lui a demandé et qui finit dans le budget et les délais promis. C’est Marc qui ne facture pas les dépassements dans le cadre de son engagement et qui en supporte les conséquences. L’agilité c’est Marc, un artisan professionnel, qui dit ce qu’il fait et fait ce qu’il dit. Il exerce son droit de conseil (bien sûr) et accepte qu’on ne décide pas comme il l’aurait souhaité. C’est aussi, bien sûr, Hervé et Marie qui paient sans discuter dès lors qu’ils ont accepté le devis de Marc et que le travail est fait et bien fait. Il ne faut pas faire d’affaire avec les amis dit la sagesse populaire. Sage sagesse en effet et qui s’applique aussi à l’agilité. Hervé et Marc ne sont pas des copains. Leurs relations sont cordiales, pas amicales. Hervé est un client, Marc est un fournisseur. Ils échangent souvent afin qu’Hervé puisse être pleinement satisfait sans que Marc enchaine d’inutiles travaux. C’est un double respect, scellé par une tractation financière : respect des choix d’Hervé, respect des efforts de Marc, plus un chèque échangé entre les deux hommes à la fin. Son montant est convenu à l’avance. C’est une relation commerciale et un travail réalisé dans un cadre professionnel. Le premier principe, celui de la collaboration est acquis (les deux hommes discutent, chacun dans sa sphère de responsabilité). Le principe de la réaction au changement aussi (Hervé peut changer d’avis, pourvu qu’il défraie Marc en cas de surcoût), ce sont des itérations courtes (Hervé et Marie reviennent un week end sur deux, sauf exception) et la validation se fait bien sur le travail réalisé (la restauration de la maison, qui avance). Le processus est bien agile. Lorsque notre boussole professionnelle ne perd pas le nord magnétique, c’est-à-dire qu’elle continue de prendre en compte la relation client/fournisseur, les attributions de chacun, les usages commerciaux en vigueur, la nécessaire organisation humaine, nous réussissons assez systématiquement les projets agiles. L’échec de bien des projets agiles est dû au fait… qu’ils ne sont pas agiles. Ils ne sont pas agiles car ils ne sont plus professionnels. Quand l’agilité, c’est d’abord « une nouvelle façon de travailler », c’est «  la suppression de toute hiérarchie », c’est « le consensus entre tous les acteurs », c’est l’entreprise sans dessus-dessous, travailler sans devis (c’est-à-dire sans engagement), la convivialité au détriment de l’organisation, le travail choisi et non commandé, le droit de faire ce que l’on veut, de ne plus rien mesurer, de ne montrer que lorsqu’on en a envie, lorsque ce sont des abstractions qui ne reposent que sur d’autres abstractions, on obtient le chaos. Et avec le chaos, vient invariablement l’échec. C’était comme ça, il y a mille ans, il y a cent ans, hier, aujourd’hui et, sans vouloir jouer à Madame Soleil, demain, dans cent ans, dans mille ans… L’agilité n’a pas changé le monde : l’artisan est agile depuis la sédentarisation de l’homme. On a juste, très modestement, appliqué ce modèle qui est le plus pertinent à notre métier. Et ça marche. Alors, pour réussir nos projets, remisons le grand soir de la révolution professionnelle. Les grandes aspirations humaines à l’idéal et les idées les plus généreuses sont l’honneur de l’humanité. Mais elles ne sont pas le quotidien, ni du « dev », ni du « PO », ni de Marc, ni d’Hervé. Il faut en finir avec l’agilité « romantique ».

Categories: Divers Tags:
  1. Guillaume
    27/01/2015 à 01:46 | #1

    L’histoire est remarquablement contée mais malheureusement un peu simpliste. Je pense que le développement logiciel n’a que très peu de rapport avec le bâtiment. Un logiciel, ce n’est pas une fenêtre, ni 10 fenêtres mais des dizaines de milliers de petits ouvrages interconnectées, un immense mikado de fenêtres, un matériau fragile aux interactions tres complexes, au point même de paraître dans certains de ses effets inexpliquable aux non-spécialistes (donc aux clients) et par moments aux développeurs eux-mêmes. Un matériau intangible et extrêmement malléable aussi, transformable a l’infini, rendant caduques tous les schémas de contrats d’ingénierie ou d’artisanat traditionnels où le donneur d’ordres pouvait effectivement comprendre ce qui était en jeu physiquement entre les pièces de l’ouvrage et se permettre de contester un choix de réalisation ou un chiffrage.

    Alors que l’évolution d’un édifice au cours du temps est étudiée et assez bien comprise depuis longtemps, nous ne sommes qu’au début de la quête de maîtrise de ce qui se passe dans un projet logiciel, car s’y conjuguent des aspects humains, souvent mésestimés, des problématiques métier et des phénomènes techniques parfois difficiles à reproduire. D’Ariane 5 à healthcare.gov, les fiascos sont nombreux pour nous rappeler que les recettes du passé ne fonctionnent pas dans ce nouvel univers et que nous devons repenser nos façons de faire.

    Les méthodes agiles sont en théorie justement une remise en cause des approches traditionnelles issues des autres disciplines et une tentative de jeter des bases nouvelles. Les critiques exprimées dans le billet me paraissent liées à des pratiques déraisonnées et dévoyées de l’agilité, extrêmement caricaturales et que je n’ai personnellement jamais rencontrées. Paradoxalement, elles ne viennent pas d’une entité cliente comme je l’ai d’abord cru, mais d’une société prestataire.

    Le mouvement software craftsmanship est avant tout une tentative de rééquilibrage en faveur de la qualité et la fiabilité des ouvrages logiciels sur de longues périodes, malmenée depuis de nombreuses années entre d’un côté des impératifs financiers court-termistes et de l’autre certains développeurs « ouvrierisés » peu sensibles à la pérennité de leur production. Je m’interroge sur les réelles motivations d’une entreprise qui caricature ce mouvement précisément créé pour éviter des catastrophes liées a des bugs, des refontes très coûteuses, apporter plus d’éthique et de responsabilisation dans la profession, et non l’inverse.

    Jusqu’à ce qu’on ait trouvé le process miracle pour obtenir une application parfaite à tous coups, je crains qu’on n’ait dautre choix que se fier à l’expertise et la conscience professionnelle des programmeurs. Autant faire en sorte de les améliorer. La commoditisation du développement logiciel n’est pas pour demain.

  2. 27/01/2015 à 09:17 | #2

    Bonjour Monsieur Darmet,
    Le mot « équipe » apparaît zéro fois dans votre article. Ne cherchez pas, vous êtes a priori passé à côté, dans votre métaphore tout du moins.
    Cordialement,
    Fabrice Aimetti

  3. Henri DARMET
    27/01/2015 à 18:20 | #3

    Bonjour M. Aimetti

    Merci de votre remarque.
    En effet, je ne parle pas d’équipe, la métaphore a ses limites :). L’article n’avait pas comme objectif de décrire ce qu’est l’agilité. Je voulais juste rappeler que l’agilité n’est pas en rupture avec en une les us et coutumes professionnels, ce que je constate parfois, hélas. Et c’est tout. Ceci dit, je suis tout à fait d’accord avec vous, l’équipe est une notion centrale dans une démarche agile. Mais cela me semble être un autre sujet. Essentiel. Mais on ne peux tout dire en une seule page :) Ne vous méprenez pas : je suis un supporter très, très convaincu des démarches agiles. Pourquoi ? Parce qu’enfin, avec les méthodes agiles, on a de vrais outils pour sortir du chaos. Et sauver nos projets, nos marges, nos soirées, nos clients. Des outils, pas une philosophie.

  4. Henri DARMET
    27/01/2015 à 19:38 | #4

    Bonjour Guillaume

    Loin de moi, la volonté de censurer le professionnel qualifié qu’est le développeur. J’approuve le Marc de mon histoire quand il donne son avis. Mieux : il fait son devoir. Cela s’appelle le devoir de conseil et cette notion s’étend jusqu’au niveau juridique. Pour avoir été expert auprès des tribunaux, j’en mesure bien toute la valeur. Le développeur est donc parfaitement légitime pour alerter son client (PO ?) sur ce qu’il convient de faire et de lui signifier les conséquences dans le cas où il ne veut pas en tenir compte. Par exemple, le développeur peut indiquer qu’il va devoir majorer ses chiffrages ultérieurs pour cette raison. Mais il ne peut aller plus loin.
    Mon Marc a tort lorsqu’il confond les rôles, lorsqu’il décide à la place de son client. Qu’il ait raison où non sur le plan technique ne change rien à l’affaire: c’est au client de décider et éventuellement de se planter. La responsabilité de Marc/du développeur s’arrête la. La relation client/fournisseur qui doit bien exister depuis que le troc se pratique n’est pas invalidée tout à coup entre 1995 et 2015 par les méthodes agiles. Ces méthodes s’inscrivent bien dans la rationalité professionnelle.
    Que l’agilité soit porteuse d’améliorations pour tous les acteurs, dont les développeurs, est indéniable et c’en est heureux. Mais ce n’en est pas la raison d’être de l’agilité. Où plutôt, l’amélioration pour le développeur étant un moteur puissant d’efficacité professionnelle, il faut la promouvoir car elle renforce la production de valeur ! La limite est quand certaines pratiques de cette amélioration viennent contrebattre l’objectif initial : à savoir, la réussite du projet.

  5. Gregoire
    29/01/2015 à 14:33 | #5

    Quel idée de faire appel à un maçon pour lui confier ce genre de travaux :-/

  6. 04/02/2015 à 17:52 | #6

    Bonjour Mr Darmet,
    Le titre de votre post m’a donné envie de le lire votre post, le « en finir avec… » est justement un de mes thèmes.
    Votre histoire est bien racontée (même si je prend un peu cher en tant que Normand :) ; Je suis naturellement d’accord dans ce cas précis. Je pense toutefois que la métaphore est simpliste par rapport à celle des projets informatique. La relation équipe / PO de type client-fournisseur que vous décrivez ressemble peu ou prou à « ferme ta gueule et fais ce que je te dis de faire ». Et là j’affirme : ce type de relation n’est pas agile (même déguisé derrière des itérations et le folklore que l’on veut bien).
    Fabrice a très justement mis le doigt sur l’absence du mot « équipe ». J’en pointe un autre : collaboration. En fait il apparait une fois mais décrit comme « une discussion, chacun dans sa sphère de responsabilité » … collaboration ??
    Vous parlez d’engagement, mais c’est un mot-valise qui souvent signifie « report de la responsabilité sur l’autre partie », un point de vue auquel je ne saurais adhérer.
    Je préfère parler de « saine ou bonne collaboration » entre les acteurs du projet, car il y a une interdépendance entre ces acteurs, et c’est une bonne chose. Le sujet hélas risque de nous emmener loin. Mais dans un nombre important d’agilité raté, il y a une mauvaise ou une non-collaboration entre les acteurs du projet. Et collaboration n’est pas synonyme de « faire n’importe quoi ». Bref, relire le manifeste ne peut pas faire de mal.

  1. Pas encore de trackbacks


huit − = 6