Bruno:
L'agilité, on en parle un peu comme une potion magique, censée tout guérir, tout fluidifier et transformer chaque équipe en une escadrille ultra efficace. Mais derrière le storytelling et les bords de plein de post-it, il y a parfois la gueule de bois de l'agilité imposée, du changement permanent ou de la tyrannie de l'urgence. Sans compter les adaptations toujours plus libres de l'agilité par ceux qui ne retiennent comme seul principe que agilité est synonyme de on fait ce qu'on veut. Mais alors, pourquoi nos organisations s'acharnent-elles à réinventer les recettes du taylorisme sous couvert de modernité ? Est-ce que l'agilité, à force de devenir un produit à vendre, ne finit pas par trahir son propre esprit ? Et surtout, qu'est-ce qu'on fout si finalement personne n'écoute celles et ceux qui font directement le travail ? Pour répondre à ces questions de souplesse, je ne reçois pas Simon Biles, mais il sait se contorsionner. Denis, bonjour.
Denis:
Salut.
Bruno:
Alors Denis, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Denis:
Ouais, je pense qu'elles sont nombreuses. Donc moi je m'appelle Denis, je suis chief of staff du département produits d'une startup qui s'appelle Fabric. J'y suis depuis bientôt 4 ans, et en dehors de ça, j'anime aussi un podcast qui s'appelle Zéro Virgule, qui existe depuis maintenant 3 ans. Un podcast dans lequel je donne la parole à des chercheuses et des chercheurs en sciences sociales, sciences humaines et sociales, pour parler du travail.
Bruno:
Du coup, on se voit aujourd'hui pour parler de l'agilité, ce fameux mot qu'on entend à toutes les sauces, de tous les côtés. Depuis 20 ans maintenant. Pour aller directement dans le vif du sujet pour moi l'agilité au début quand j'ai commencé à apprendre le concept pour moi c'était une pour vocation de, de couper entre guillemets on va dire le travail des devs d'un contact permanent avec les clients ou les demandeurs ou les prescripteurs comme on veut, pour qu'ils puissent se concentrer sur leur travail en mode pendant le sprint tu fais ce que t'as à faire et au moins t'es pas constamment perturbés par les autres, donc tu vois je le voyais quand même avec une vocation un peu noble, de rendre les développeurs et développeuses plus capables de mieux travailler et donc de moins avoir de contexte switching, toi aujourd'hui après ces 20 ans de mise en place de l'agilité un peu partout, à toutes les sauces, est-ce que pour toi le résultat est probant ou est-ce qu'on est sur une catastrophe de la manière dont c'est fait ?
Denis:
Alors c'est jamais l'un ou l'autre c'est un peu nuancé plus exactement ça fait 40 ans à peu près parce que les premiers signes d'agilité on va dire, les premiers même le premier framework agile c'était dans les années 80 et ça s'est inscrit dans une volonté de, créer une rupture avec la façon dont le développement logiciel était fait jusqu'alors, C'est-à-dire qu'il y avait une approche très industrielle du développement et très séquentielle. C'est-à-dire qu'on réfléchissait d'abord à l'écriture d'une documentation expliquant ce qu'on souhaitait, on passait ensuite à une phase de réalisation et enfin à une phase de test et de mise en production. Et cette approche qui était très industrielle ne fonctionnait pas, je pense que je t'apprends rien en disant que travailler comme ça ne fonctionne pas dans le développement logiciel en particulier parce qu'il y a beaucoup de complexité, on apprend beaucoup de choses en faisant et on peut difficilement avoir une approche. Très prédictive dans ce contexte là et donc l'agilité ce qu'elle a voulu à partir des années 80 et son explosion a été en 2001, ça a été de changer totalement cette approche-là, en disant ça, ça ne fonctionne pas, on a besoin de découvrir des choses, on a beaucoup d'inconnus et donc ce qu'on va faire, c'est qu'on va émettre des hypothèses, on va vérifier ces hypothèses-là, on va apprendre de ce qu'on met en place et on va avancer comme ça et s'améliorer. Ça a été très influencé par l'approche Lean également dans cette recherche d'amélioration continue d'apprentissage. Ça a été aussi très influencé par des approches scientifiques qui consistent à dire on ne sait pas ce qu'on va découvrir donc émettons des hypothèses et vérifions-les. Et à partir de là on verra ce qui se passe et ça a amené à un vrai changement d'approche et en soi je trouve que ça a été, en cela un succès, c'est à dire que aujourd'hui ça paraît, à la fois, enfin je pense que pour tout le monde c'est intégré le fait que de passer des mois et des mois à écrire une documentation avant de coder n'a aucun sens et c'était pas le cas dans les années 60 ou 70 Donc en soi il y a un vrai changement qui est intéressant et qui est à mettre vers, c'est une victoire je pense, ça a permis aussi cette agilité là, enfin plutôt tout le business qui est derrière et comment ça a évolué, ça a permis de mettre en avant toutes les limites et les faiblesses du management dans le développement logiciel. Le fait que les équipes aient besoin d'une certaine autonomie, de pouvoir accéder directement aux utilisateurs de comprendre le métier, de comprendre pourquoi ils font ça et que les développeurs et développeuses ne sont pas des, excuse-moi l'expression des personnes là juste pour pisser du code et bien ça, je trouve que ça a été un des moyens qui a permis cette évolution là donc en soi c'est très positif, et ce qui a été par contre plus négatif, tu l'as évoqué c'est que ça a été on va dire ça a explosé au début des années 2000 par ce qui s'est appelé le manifeste manifeste agile, qui en fait 17 consultants qui ont expliqué pourquoi ils ne voulaient pas travailler comme c'était jusqu'ici, ce que j'évoquais tout à l'heure, mais ça reste des consultants qui ont des choses à vendre et qui ont un business à faire tourner et donc ils ont mis en place tout un tas de trucs, notamment des certifications, qui ont créé tout un business très rentable sur l'agilité et qui dit business très rentable dit beaucoup de raccourcis qui ont été pris pour rendre ça encore plus facile à vendre plus facile à expliquer, et sur le papier, plus facile à implémenter. Et c'est là où on est arrivé avec une sorte de prêt-à-penser et de modèle, tu disais tout à l'heure, t'es laurien au final, en disant c'est facile, voilà comment il faut faire. Et en mettant en place ça et ça et ça, vous allez arriver à tel résultat. Et très loin au final de l'approche initiale, la réflexion initiale de dire on ne sait pas et on va voir ce qui se passe et on va vérifier des hypothèses. Donc c'est là toute la dérive, qui est une dérive évidemment financière et qui s'explique par le fait que, pour vendre des concepts il faut les simplifier à outrance et il faut toujours, créer des nouveaux concepts pour créer des nouvelles formations des nouveaux coachings etc.
Bruno:
Il y a beaucoup d'éléments dans ta première réponse sur laquelle j'aimerais revenir, déjà tu as évoqué un peu le mode de fonctionnement waterfall qu'on avait effectivement avant, on a fait un épisode il y a longtemps avec Michel Verdun on parlait justement de la méthode Waterfall, et moi dans les quelques formations que j'ai pu faire en tant que Scrum Master ou des formations autour de l'agilité diverses et variées, j'avais l'impression que ce qui ressortait régulièrement c'est que le Waterfall fonctionne quand même encore aujourd'hui dans des contextes un peu particuliers et notamment l'élément que j'ai eu l'impression de retenir à l'époque c'était que le Waterfall est parfaitement adapté quand tu sais exactement où est-ce que tu veux aller, quand tu sais exactement ton projet mais quand t'as une espèce d'incertitude sur le où, l'agilité reste comme un meilleur moyen d'y aller quoi.
Denis:
Le waterfall, c'est très bien quand tu es dans un contexte prédictif, où tu sais, soit tu connais très très bien où tu en es, ou ce qu'il y a à faire, et qu'il y a très peu de chances d'avoir des surprises, ou soit c'est parce que c'est quelque chose qui peut se dérouler à l'infini, et dans ce cas-là, on sait ce qu'il y a à faire, et donc pas besoin de se poser des questions tous les jours, toutes les semaines, comment on va faire évoluer ce qu'on vient de découvrir. Donc dans ces cas-là, effectivement, le waterfall ou l'approche en V, toutes les méthodes prédictives fonctionnent parfaitement. Par contre, quand tu es dans une situation où tu as beaucoup de nouveautés, beaucoup de complexités, beaucoup d'inconnus, là, le waterfall n'est pas possible et il faut avoir une démarche consistant à faire peu de choses, travailler sur un petit spectre et travailler à un petit nombre de personnes et avancer pas à pas.
Bruno:
Quand tu parles d'incertitude, parce que tu vois, pour moi, comment dire, dans un mode waterfall, si je sais exactement à quoi va ressembler ou comment va fonctionner mon logiciel, pour moi, le waterfall s'adapte bien, même si tu peux avoir un risque que la complexité de mettre ça en place est peut-être plus élevée que ce qu'on avait estimé, donc risque à ce que ça prenne du temps. Tu vois, quand tu parles de surprise ou d'incertitude, tu parles aussi de ce genre d'incertitude c'est à dire qu'en fait c'est plus compliqué que ce qu'on pensait à faire, donc pour toi dans ces cas là même si je sais exactement où je veux aller mais que le chemin est pas forcément très clair il vaut mieux passer sur de l'agile que sur du waterfall.
Denis:
Après j'ai pas connu d'expérience en développement logiciel où il n'y a pas de surprise, où ce qu'on pensait faire c'est pas au final ce qu'on fait ça m'est jamais arrivé, donc peut-être que ça existe dans des cas mais moi quand je parlais plus de modèles prédictifs je pensais même pas je pensais même pas. À forcément le développement logique. Je pensais, par exemple, quand on veut construire une maison, quand on est dans un... Comment dire ? Sur un terrain qui est très... On comprend ce qu'il y a à faire, on a exactement les plans en tête, il y aura quelques surprises, mais qui seront minimes et qui ne vont pas remettre en question ce qui est construit, ce qu'il y a à construire. Et donc, dans ce cas-là, ça ne sert à rien toutes les semaines de réfléchir à comment on va pouvoir faire évoluer le truc. On va, effectivement, s'adapter parce qu'il y a toujours des surprises, un artisan qui ne peut pas venir, quelque chose qui a cassé qui ne devait pas casser mais globalement on sait ce qu'il y a à faire là où, l'expérience que j'aime en tout cas dans le développement logiciel c'est que très très souvent au bout de quelques jours on se dit ah merde en fait il y a quantité de choses qu'on n'avait pas prévues on touche du doigt des trucs on pensait qu'elle allait être facile mais en fait c'est très compliqué et à l'inverse, Ou alors, en faisant expérimenter ce qu'on est en train de produire par l'utilisateur, on se rend compte qu'on a des feedbacks auxquels on n'avait pas du tout pensé. Ou même que le besoin n'est pas forcément celui qu'on avait imaginé. Donc voilà, c'est pour ça qu'au moment de développement logisiel, j'ai pas connu de situation où on pouvait faire autrement qu'en s'adaptant et qu'en avançant vraiment petit pas pour petit pas.
Bruno:
Tu as évoqué aussi la notion de taylorisme, alors c'est vrai que dans notre métier il y a beaucoup de mots qu'on voit emprunter au monde du BTP, tu as évoqué effectivement l'analyse de la maison, mais quand on parle de maîtrise d'ouvrage il y a beaucoup de termes qui viennent du monde du BTP, mais c'est vrai que ce qui est intéressant c'est qu'il y a beaucoup de méthodologies, dites agiles qui viennent du monde de l'automobile donc le terme de taylorisme aussi du coup est forcément, adapté, la méthode Kanban par exemple, vient le monde automobile, qui pourtant effectivement est un métier extrêmement industriel, on réplique de manière identique certains gestes et de l'assemblage de pièces. Comment ça se fait que notre métier, qui pourtant n'est pas si industriel que ça, puisse reprendre des méthodes qui viennent d'un monde très industriel ?
Denis:
Alors, on pourrait en débattre pendant longtemps. Il y a plusieurs choses à décortiquer là-dedans. Déjà, le taylorisme, c'est une approche scientifique du travail qui consiste à dire qu'une approche de consultant, parce que Taylor était un consultant, consistant à avoir une approche très mécanique du travail. En disant, le travail, je peux le diviser, une chaîne de production, je peux la diviser en gestes, et chaque geste est une pièce d'un mécanisme, et en le décomposant, je vais pouvoir m'assurer d'avoir une plus grande efficacité, on va pouvoir produire plus vite. Ce qui sur le papier est vrai et sur des sur certains. Certains types d'exercices certains types de métiers ou plutôt de besoins de production peut se vérifier mais les limites de ça c'est que la personne devient un mécanisme, sa subjectivité, son intelligence n'est plus utilisée elle est juste un rouage dans la mécanique de la production et quand on ne fait pas appel, à la subjectivité et à l'intelligence des personnes, quand on leur demande pas de faire un beau travail, d'avoir une fierté dans ce qu'elles font, les personnes ont bizarrement du mal à trouver un intérêt dans ce qu'elles font, elles ont du mal à s'accomplir, et ça entraîne une quantité de choses un petit peu désastreuses pour les personnes, et donc pour la production. Mais Tellurisme a eu un succès retentissant qui a amené beaucoup de personnes à se dire « tiens, c'est la bonne façon, c'est la bonne approche ». Et qui ont essayé de le calquer sur quantité d'autres choses qui n'ont aucun rapport, que tu viens d'évoquer. Et malheureusement, c'est ce qui arrive aussi dans le développement logiciel, alors que ce n'est pas du tout adapté ou très peu adapté. Après pour pour Kanban ça vient plus du Lean que de l'agilité même si les deux sont très liés notamment Scrum qui est très ouvertement inspiré du Lean, ces deux on va dire cousins plus ou moins éloignés mais effectivement ça vient. De Toyota donc du secteur industriel et automobile, c'est pas parce que ça vient de ce secteur là qu'on peut pas du tout l'utiliser en ce sens où si on réfléchit à l'essence de Camban ça consiste à visualiser ce qui se passe à limiter l'encours pour éviter d'être dans une situation de surcharge de travail, à mesurer pour comprendre ce qui se passe et pour pouvoir prendre des actions en fonction de ce qu'on observe mais aussi de ce qu'on mesure et à continuellement améliorer ce qui se passe, et donc ça, ça peut fonctionner dans le secteur industriel mais ça peut fonctionner partout. Le fait de visualiser limiter, mesurer s'améliorer, ça peut fonctionner en tout et ça peut fonctionner dans un flux de production de développement logiciel, la mise en pratique ne sera pas exactement la même voire pas du tout mais le principe, la philosophie, je ne sais pas si c'est le bon terme, autour de ça pourra être adapté voilà.
Bruno:
Mais en même temps, ce que t'évoques là sur la philosophie de Kanban, en fait, d'une certaine manière, on peut le reboucler avec ce que t'évoquais aussi tout à l'heure. C'est que quand tu dis, si on prend du recul et qu'on regarde le principe fondamental de Kanban tel qu'il est utilisé chez Toyota, on peut l'appliquer ailleurs. En fait, c'est aussi ça un peu qui amène tous ces vendeurs de formation, comme tu les appelles, à se dire, on reprend le principe fondamental de tel truc, tel truc, tel truc. Et puis on va créer une nouvelle méthode une nouvelle manière de l'implémenter et on va vendre ça à prix d'or et à coût de certification à droite à gauche.
Denis:
C'est les limites à la fois des formations et des certifications, déjà de base au-delà de ce qu'on vient d'évoquer c'est que il y a des études qui montrent que les formations dans l'immense majorité des cas n'ont absolument pas d'impact. Sur l'amélioration de ce qui est mis en pratique dans les entreprises et pour plein de raisons et on pourra en parler mais la raison principale c'est que souvent la formation est considérée comme un levier d'apprentissage qui va permettre, de facto aux personnes de comprendre comment appliquer les choses et comment s'améliorer et comment être meilleur dans leur travail. Sauf que ça nécessite un temps de pratique, un temps de questionnement qu'on donne pas aux personnes, et un temps d'expérimentation qu'on donne pas aux personnes quand elles reviennent de formation. Et aussi la disponibilité de la personne qui a donné la formation pour les accompagner dans la mise en pratique de ce qu'elles ont pu apprendre. Et donc ce qui fait que déjà de base les formations fonctionnent pas très bien mais là les certifications et... Qu'on a pu voir dans l'agilité mais qu'on voit un peu partout maintenant, enfin pas maintenant mais qu'on voit un peu partout ça concerne pas que l'agilité, cette volonté de certification c'est une industrialisation on va dire du secteur mais c'est aussi comme on peut le reconnaître les personnes qui ont. Lancé les certifications dans l'agilité donc c'est, je pense à ce Roland des Schwabers, c'est Schwabers je pense qui a popularisé ça, c'est que l'avantage de certification c'est que ça fait connaître le sujet, donc ça a participé à l'essor et au succès de l'agilité. Donc il y a un aspect positif, c'est que plus il y a eu de certification, plus de personnes ont voulu copier en disant, moi aussi je veux être certifié, moi aussi je veux avoir cette légitimité-là. Et donc ça a permis d'amener tout un tas de choses positives, mais l'aspect négatif de ça, c'est que ça a créé une sorte d'uniformisation, d'image mentale selon laquelle on peut tous appliquer la même chose, et qu'il suffit de deux jours de formation pour savoir. Comment aider une équipe, quel que soit son contexte. sauf que c'est très long, il faut des années de pratique, il faut avoir un certain recul sur ce qu'on a appris il faut aussi reconnaître que le contexte est différent d'une équipe à une autre est-ce qu'il fonctionne avec une équipe va pas en fonction avec une autre, et donc tout ça pour dire que ces certifications et ces formations, leur grosse limite c'est qu'elles vendent quelque chose qui est impossible elles vendent l'idée que en quelques heures, quelques jours on va pouvoir être suffisamment armé pour faire face à, quantité de contextes différents et on le voit beaucoup, notamment avec l'arrivée des certifications pour, les frameworks comme SAFE, mais il y en a d'autres il y a LES, il y a Scrum of Scrum qui sont des frameworks qui sont destinés à, non pas à une équipe, mais à l'ensemble de l'entreprise qu'est-ce qu'on peut mettre en place pour que l'ensemble de l'entreprise soit, plus efficace, plus rentable, plus agile, etc. Et là, je trouve que c'est encore plus... Encore plus qu'Hasgul parce que je ne vois pas comment en quelques jours ou quelques heures on peut savoir comment changer une entreprise dans sa globalité il y a tellement de jeux qui se jouent de jeux de pouvoir, de jeux politiques de relations humaines, de stratégies différentes entre les personnes de contexte business, de marché qui sont différents je ne vois pas comment on peut en quelques jours avoir la préception de dire ok c'est bon les gars il faut faire exactement comme ça et ça va fonctionner, Et ça, je trouve que c'est le gros danger de ces formations-là et surtout de ces croyances qui sont véhiculées par les formateurs, les conférenciers, les conférencières qui sont là pour vendre quelque chose. Et ce qu'ils ont à vendre, c'est toujours leur savoir et l'application de leur savoir.
Bruno:
Je ne sais pas comment me positionner. Je ne suis pas sûr de... J'évoquais en intro, pour moi, un des problèmes avec toute cette diffusion de l'agilité, c'est qu'il y a beaucoup de directions d'entreprise, ou dirigeants d'entreprise qui se disent, en fait, l'agilité, le but, c'est de rester souple et on peut faire un peu ce qu'on veut. Et j'ai souvent eu le sentiment, en fait, que c'est justement cette adaptation, du... En fait, on prend le manifeste d'origine et on cherry-pique un peu ce dont on a envie. Et c'est justement le fait qu'on cherry-pique qui fait que c'est mal intégré. Et j'ai souvent eu le sentiment que si, au contraire, les entreprises appliquaient stricto sensu le manifeste, en faisant exactement tous les rituels, tout ce qui est prévu, quel que soit leur contexte, que ça fonctionnerait justement mieux, tu vois ce que je veux dire ou pas ?
Denis:
Oui, oui, tout à fait.
Bruno:
Tu vois, j'ai justement le sentiment que c'est ce cherry picking, cette adaptation au contexte qui fait que alors peut-être qu'après c'est les choix qui sont mal faits, mais j'ai l'impression que les gens devraient plus s'appliquer à la lettre ce qui était prévu plutôt que de s'adapter à leur contexte.
Denis:
Alors oui, non, je vais te dire pourquoi de mon point de vue, ça peut pas marcher c'est que, C'est que là, on est juste dans l'application de pratiques. Et une pratique, au final, tu peux mettre en place n'importe quel process si il y a une certaine culture dans l'entreprise, s'il y a certains comportements face à telle ou telle situation. S'il y a certaines croyances. Les pratiques peuvent être totalement tordues pour ne pas amener ce qu'elles étaient censées amener. Et l'un des éléments fondamentaux de l'agilité, et notamment de son framework le plus connu qui est Scrum, c'est de dire qu'il faut redonner du pouvoir à celles et ceux qui font. Il faut redonner du pouvoir décisionnel aux équipes, il faut leur donner la possibilité, la capacité de définir comment elles vont travailler. Et sauf que ce que j'ai pu voir souvent c'est que les entreprises elles ont juste une approche, de process en disant on met en place des nouvelles pratiques vous allez faire un daily meeting vous allez faire des itérations de deux semaines etc etc mais cette relation de comment on change la redistribution du pouvoir comment permet à une équipe d'être autonome comment lui donne du pouvoir de décision il est très peu évoqué voire pas du tout et donc dans ce cas là on. On donne des pratiques, mais sans le sens derrière, et donc ces pratiques, au final, ne font que, sans que, comment dire, un coup de peinture, on reproduit la même chose, avec des noms un petit peu différents, avec des rôles qui apparaissent, d'autres qui disparaissent, des mots qui apparaissent, d'autres qui disparaissent, mais en soi, les gens ont bougé de place, la structure a changé, mais l'organisation n'a pas vraiment changé. C'est à dire que la structure c'est l'aspect qu'on peut visualiser c'est à dire un organigramme la répartition des personnes mais l'organisation c'est à dire comment les personnes travaillent comment elles résolvent des problèmes, comment elles se comportent face à telle ou telle situation ça ça n'a pas changé parce que c'est pas ce qui a été évoqué, et on est juste dans une approche, très structurée et non organisationnelle.
Bruno:
Oui donc on est effectivement comme tu le dis sur un coup de peinture c'est à dire qu'en fait on change des titres on change un peu des places oui je vois ce que tu veux dire, c'est-à-dire que tu appliques des process sans appliquer la philosophie qui va effectivement derrière donc tu imposes une nouvelle pratique, ce qui forcément quand tu imposes une nouvelle pratique tu as aussi toute la notion de conduite de changement qu'il faut aussi mener après en interne qui n'est pas toujours aussi idéalement bien menée c'est.
Denis:
Ça et puis surtout la question qu'il faut se poser c'est qu'est-ce qu'on souhaite accomplir ? Pourquoi on fait ça ? Qu'est-ce que ça va nous permettre de faire ? Qu'est-ce qui sera différent quand on y sera arrivé ? Et ça, c'est assez peu évoqué. Ce qui est évoqué, c'est souvent dire on va aller plus vite, sauf que l'agilité ne permet pas vraiment d'aller plus vite. Au contraire, surtout au début, enfin, c'est lié à tout changement, mais au début, ça ne permet pas d'aller plus vite, au contraire, mais ça permet surtout de trouver un rythme soutenable qui va nous permettre un peu prédictif dans notre production et qui va nous permettre d'avancer régulièrement. Et, On ne va pas forcément aller plus vite. Et ce qui m'ennuie là-dedans, c'est que souvent, par mimétisme, par volonté de copier ce qui se fait un peu partout, ou parce que c'est un effet de mode, on va juste dire il faut être agile. Mais pourquoi ? On s'en fiche d'être agile. Qu'est-ce qu'on veut faire avec ça ? Et tu le retrouves un petit peu partout. Il faut être lean, il faut être agile, il faut être ceci, il faut être cela. Mais pourquoi ? Et souvent, c'est même pas évoqué, parce qu'on est juste dans une... Raccourcis, une sorte de paresse mentale, disant les autres le font, donc on va le faire.
Bruno:
C'est vrai que moi, ce que j'ai beaucoup vu dans les organisations dans lesquelles j'ai pu travailler, c'est souvent ce principe d'agilité, il est mal compris au niveau des directions. Ce que j'évoquais en intro, souvent t'as des dirigeants et des dirigeantes qui vont retenir le fait que on va être souple, on va être agile, donc on fait un peu ce qu'on veut. Mais du coup, on reste souple. Et effectivement, comme tu le dis, pour moi la vocation de l'agilité c'est qu'on peut, répondre aux changements plus rapidement on est capable de s'adapter plus rapidement mais effectivement ce qui est souvent retenu c'est pas on va s'adapter plus rapidement c'est on va travailler plus rapidement il y a cette impression de gain de vitesse ce qui est pas forcément l'objectif premier de l'agilité et.
Denis:
Ça amène une sorte d'intensification du travail alors comme tu dis le but c'est de s'adapter c'est d'assurer que ce qu'on fait correspond à ce pour qui c'est destiné que ce soit des utilisateurs, des clients etc, que ce qu'on fait permet de produire de la valeur et que au final on ne perde pas beaucoup d'argent dans du temps investi pour des choses qui ne vont pas être utilisées, Mais ça ne veut pas dire qu'on va aller plus vite. On va peut-être livrer plus fréquemment, c'est sûr, on va livrer plus fréquemment. Mais globalement, on ne va pas forcément aller plus vite. Mais par contre, ce qu'on va livrer va correspondre à un besoin et donc va permettre de... On va pouvoir capitaliser sur la valeur qui est produite beaucoup plus régulièrement.
Bruno:
Est-ce que aussi dans tout ce marché qui a été créé de formation il y a une volonté aussi de simplifier fortement la méthode tu l'évoquais pour faire des formations qui tiennent en quelques jours, là où effectivement il faudrait j'ai bien aimé ce que tu disais tout à l'heure je pense que c'est aussi un petit peu provocateur quand tu disais que c'est des réflexions de consultants tu parlais du Fordisme qui était une réflexion de consultants de découper le travail en gestes, mais il y a aussi quand même une simplification de ces méthodes-là, de la vente de manière unitaire, sans aller accompagner tout le changement et tout le travail qui est nécessaire sur le plus long terme.
Denis:
Mais les signataires du Manifeste Agile sont tous des consultants. Il ne faut pas oublier, en fait. Donc, ce qui est devenu l'agilité, ce n'est pas une surprise en soi. Ce sont des personnes qui avaient une volonté business derrière et qui n'étaient pas, je veux dire, émus d'une volonté de changement du monde. Il y avait une volonté première de se faire de l'argent en tant que consultant. Et d'ailleurs, ça a très bien fonctionné pour eux. Et d'ailleurs, s'ils ne se sont jamais réunis après, c'est pourquoi, et ils le disent eux-mêmes, c'est parce qu'ils sont concurrents. Ils sont concurrents et donc ils ont besoin, les uns et les autres, de pouvoir gagner des marchés, de pouvoir signer avec des clients. Et ils se retrouvent souvent confrontés à répondre à des mêmes clients. Donc, en soi, ce n'est pas une surprise. Et je ne veux pas non plus... Trop, comment dire, les pointer du doigt, parce que c'est pas que ça, c'est aussi, il y a eu une, allez on va dire, entre 2015 et 2018, il y a eu une sorte d'effervescence de l'agilité, avec beaucoup d'entreprises qui souhaitaient recruter, s'y mettre, etc. Et donc il y a eu beaucoup de personnes qui se sont rêvées du jour au lendemain après une formation de deux jours à être présentées comme des agents du changement des agilistes, des coachs agiles, des scramasters etc avec très peu d'expertise et de recul sur ce qu'ils faisaient et donc étaient juste dans l'application un petit peu bête de il faut faire un day-limiting, il faut faire une rétrospective, et ce qui je dis pas que ça n'amène pas des choses mais c'est très limité. Et amener un changement dans une entreprise, ça touche à beaucoup de sujets, ça touche à la dynamique de travail, ça touche au bien-être des personnes, ça touche aussi au business, parce que quand on amène des changements, il va y avoir beaucoup, on va instaurer un peu un chaos, parce que les gens ne vont pas forcément comprendre ce qui se passe, on va ralentir la production, donc il va y avoir des conséquences financières derrière. Il va y avoir aussi des conséquences sur les formations des personnes, leur accompagnement. Donc ça touche énormément de choses, énormément de sujets sur lesquels on n'est pas formé quand on suit juste une formation de coaching ou une formation sur l'agilité. Donc il y a tous ces ensembles à prendre en compte, c'est que effectivement il y a une standardisation et un nivellement par le bas en. Vendant des certifications et des formations en deux jours qui sont une sorte de prêt-à-penser en disant voilà au bout de deux jours on pourrait faire ça alors que c'est faux mais il y a aussi toute une vague de personnes qui sont arrivées en très peu de temps qui n'étaient pas formées et pas forcément compétentes pour ça et qui ont créé une situation où d'ailleurs on le voit très bien aujourd'hui, c'est que, ce secteur est en crise profonde parce qu'il y a eu beaucoup de déceptions, beaucoup d'entreprises qui ont été déçues, qui ont investi massivement dans tout cela et qui n'ont pas vu de changement et qui ont dit mais à quoi, Nous sert le fait de passer par des coachs agiles, des scrum masters, etc. On ne voit pas la valeur qu'ils produisent, qu'ils amènent. Et aujourd'hui, c'est un secteur qui est profondément en crise. Et d'ailleurs récemment j'étais à un Agile Tour à celui de Bordeaux et j'ai assisté à plusieurs conférences où les personnes expliquaient que pour la première fois depuis des années elles ne trouvent pas de mission. Elles n'ont pas de perspective les entreprises ne sont plus tout au moins intéressées, passer par des personnes travaillant dans l'agilité et donc c'est aussi une conséquence de tout ce qu'on vient d'évoquer.
Bruno:
Pour toi toute cette... Toute cette évolution des principes d'agilité, à quel point ça a été délétère pour les développeurs, développeuses et pour notre profession au global ?
Denis:
C'est difficile à dire parce que ça m'ennuie de parler au nom de tout le monde. Donc je vais peut-être parler juste de mon point de vue. De mon point de vue, c'est que ça a créé des situations où on a très vite associé l'agilité à un truc, des fois un peu le nez rouge du clown parce que les rétrospectives au thème Disney, parce qu'on fait des dessins, des agiles games, etc. Donc il y a toute une partie aussi où ça a été décrédibilisé parce qu'il y avait ce côté, ouais, il faut que ce soit fun. Alors que non, il ne faut pas que ce soit fun, on est là pour travailler et pour faire, on fait face à des sujets qui sont importants, et au final on est là aussi pour rapporter du pognon, donc on n'est pas là pour faire la Macarena. Et il y a déjà cette partie-là qui a décrédibilisé vraiment et qui a créé une situation, enfin l'agilité et qui a créé une situation où en tant que développeur ou développeuse on s'est dit mais qu'est-ce que c'est que ce cirque ? Il y a aussi toute une partie où on est dans une application un petit peu froide ou mécanique de process, qui se faisait au détriment du métier du développement logiciel, au détriment de la subjective intelligence des personnes qui exercent ce métier-là, et on se retrouvait avec des personnes qui venaient de l'extérieur nous expliquer comment travailler. Ce qui est horrible parce qu'on se retrouve encore une fois avec une approche taylorienne consistant à dire que le cerveau pensant l'organisation du travail et la structure du travail est à l'extérieur de l'entreprise mais de l'équipe et pas dans l'équipe. Et donc on est arrivé avec cette approche d'imposition de pratique qui peut avoir cet effet de pushback en disant mais pour qui vous prenez moi je fais ce métier depuis 10 ans, 15 ans ou 20 ans je sais un peu ce que j'ai à faire quoi, Donc il y a tout ça qui a créé, je trouve, une sorte de détachement ou même de moquerie vis-à-vis de toute personne incarnant cette agilité-là. Je ne compte plus le nombre de fois où j'ai entendu des développeurs et des développeuses se moquer d'un ou d'une coach agile, se moquer d'un scrum master en disant « bah oui, ils font leur petit machin, c'est bien mignon, mais bon, voilà ». Donc, c'est tout cela combiné qui, je pense, a contribué à créer une distance entre les développeurs et les personnes se présentant comme agilistes. Et d'ailleurs, aujourd'hui, quand on va à des conférences agiles, on voit très peu de développeurs. C'est assez rare même de voir des conférences de développeurs et développeuses. On voit beaucoup de conférences données par des consultants, par des coachs, par des scrum masters, mais très peu de développeurs et développeuses. Alors que ça a été un mouvement qui a été initié par des développeurs et développeuses, mais qui ont déserté ces conférences et ces secteurs-là, ce qui montre bien qu'il y a une distance qui s'est créée entre ces métiers-là.
Bruno:
Ce qui est intéressant, quand tu rappelles le fondamental de la méthode agile type Scrum, qui est de redonner le contrôle de ce qu'on doit faire à l'équipe, ce qui est marrant, c'est qu'on voit aujourd'hui que tu as toutes les boîtes qui appliquent le Scrum comme étant, comme tu le dis, une succession de process et de méthodes de travail. Et on voit maintenant certaines entreprises qui organisent leurs équipes, que ce soit en mission team ou en impact team, comme on dit, mais qui ont des équipes qui fonctionnent en Scrum mais une organisation globale par dessus qui est en mission team mais en fait ce que tu dis c'est qu'à la base ça c'était le principe fondateur.
Denis:
De la méthode agile l'agilité ce qu'elle voulait c'était de redonner du pouvoir à celles et ceux qui font en se disant on est trop mis de côté on y a trop de distance avec les utilisateurs, avec le métier il y a trop de distance par rapport à la prise de décision sur, ce qu'on doit livrer, comment on s'y prend, reprenons ce pouvoir là. Tu le retrouves pas que dans l'agilité tu le retrouves dans l'extrême programming également et cette proximité avec l'utilisateur ou la représentante, de l'utilisateur et cette proximité aussi dans la prise de décision du comment, commande au travail etc et ça, ça s'est perdu je ne dis pas que c'est absent et que tout est nul mais il y a quand même beaucoup d'entreprises qui se sont retrouvées dans cette situation là et comme tu parles de mission, de pouvoir décisionnel c'est important il faut avoir conscience que si on souhaite mettre en place l'agilité, il faut que ça aille de pair avec ça si on souhaite avoir un résultat intéressant, et le résultat intéressant je le rappelle, c'est d'apporter de la valeur à des utilisateurs et des utilisatrices le plus rapidement possible.
Bruno:
Du coup, est-ce que pour toi, il faut arrêter l'agilité ? Il faut la remplacer par autre chose ? Et c'est quoi pour toi ? Donc là, ton enregistre, on est fin 2025, mais ton épisode va être diffusé en début de 2026. Qu'est-ce qu'on peut souhaiter à l'agilité sur l'année 2026 ?
Denis:
Difficile à dire, alors moi quand je dis tout ça, c'est pas pour dire qu'il faut tout jeter, et que tout est foutu, l'agilité déjà est très mal en point, je l'ai évoqué tout à l'heure, c'est un secteur qui est en crise aujourd'hui, ce que je souhaiterais c'est pas forcément lié à l'agilité c'est qu'on prenne le temps d'écouter les personnes qui font, d'accorder du crédit à leur point de vue et à ce qui est nécessaire de faire pour améliorer ce qu'elles font et cette écoute, cette prise en compte pour moi elle est fondamentale, elle est souvent oubliée, et c'est ça que je souhaite vraiment pour les équipes pour les personnes qui travaillent qu'on les écoute et qu'on prenne en compte leur subjectivité, leur intelligence c'est qu'on leur permette de faire du beau travail pour, une fois de plus, pour réussir à faire que le business soit un succès. Les deux ne sont pas incompatibles, au contraire. Et c'est ça que je trouve fondamental et qu'il faut amener que ce soit l'agilité ou pas. Donc cette écoute, cette prise en compte et cette relation avec le business.
Bruno:
Est-ce que tu crois que c'est une philosophie qui est applicable dans tout type de boîte ? Ce que je découvre, de manière assez récente avec mes nouvelles activités, où je suis plus en mode, on va dire effectivement consultant, mais on va dire que je découvre que tu as quand même deux types d'entreprises dans lesquelles tu retrouves de la tech. Tu as les boîtes qui sont effectivement tech, où du coup, en fait, le cœur du produit, le cœur de ce qui est vendu, c'est effectivement de la tech. Et je pense que là il y a quand même un besoin d'agilité de manière assez forte et après t'as des boîtes sur lesquelles la tech est là mais c'est pas le coeur du métier c'est pas le coeur de la boîte et dans ces boîtes là effectivement la tech est une unité de production, est une fonction support ils sont là effectivement pour produire quelque chose qui permet aux équipes qui drive l'activité de réaliser leurs chiffres, mais du coup ça veut dire aussi que je trouve que c'est plus compliqué d'amener ce principe là, comme tu disais, d'autonomie de ce principe de mission team ou d'impact team, dans des contextes où au final la tech a pas le même apport que dans une boîte tech.
Denis:
Ouais tout à fait je suis tout à fait d'accord avec toi c'est pas une fin en soi l'agilité il faut pas le faire absolument parce que tout le monde le fait parce que etc, il y a plein de possibilités de travailler il y a plein de possibilités de réussir son business, l'agilité est un moyen parmi tant d'autres, est une trousse à outils parmi tant d'autres. Et donc, chaque entreprise n'a pas à mettre en place ça. Et ce que tu dis, moi, je suis totalement d'accord avec toi, il y a des contextes où ça ne va pas marcher. Donc, pourquoi s'emmerder à... Elle rentrait dans une sorte d'illusion d'agilité où on fait des rétros, des délits, des machins alors que ça n'a pas fonctionné c'est pas ça qu'il faut faire en fait donc je suis ton avis, il faut réfléchir aux problèmes qu'il y a à résoudre il faut les comprendre, prendre du temps à les analyser et avancer sans forcément utiliser l'agilité.
Bruno:
Du coup on se dit que toutes les personnes qui écoutent ce podcast on comprend que, quand une direction nous dit on va faire de l'agilité parce que ça nous permet d'aller plus vite, il faut leur expliquer alors non l'agilité ne nous permet pas d'aller plus vite ça nous permettra de nous adapter plus rapidement à des changements s'ils se présentent, ça ok, mais du coup comment est-ce qu'il faut s'organiser, se structurer, se processiser, sur ces trois aspects là pour réussir à aller effectivement plus vite, qu'est-ce qu'on peut proposer à nos équipes dirigeantes pour leur dire si vous voulez aller plus vite voilà un peu la chose à faire.
Denis:
Alors c'est une question qui n'est pas simple parce que un changement d'entreprise il y a beaucoup d'acteurs qui interviennent avec des contextes très différents, moi ce que je conseille toujours à une équipe de direction qui souhaite amener ce changement c'est déjà de se poser la question de qu'est-ce que vous souhaitez vraiment faire Qu'est-ce que vous souhaitez ressortir de tout ça d'un point de vue business et d'un point de vue organisationnel ? Qu'est-ce que vous voulez avoir ? Qu'est-ce que vous voulez voir advenir ? Et ensuite, comment vous, en tant qu'équipe de direction, vous allez pouvoir l'incarner ? Et comment vous allez pouvoir faire en sorte que, parce que c'est souvent des comportements qui vont devoir changer, comment vous devez faire en sorte que toutes les personnes qui incarnent l'autorité, le pouvoir, la légitimité dans votre entreprise puissent avoir ces nouveaux comportements-là, comprennent déjà ce que c'est son nouveau comportement et comment ils peuvent les mettre en place. Et déjà, rien que ça, c'est très très long à mettre en place parce que c'est déjà être d'accord sur ce qu'ils souhaitent voir advenir, les comportements nécessaires pour que ça advienne, faire comprendre ça et faire rendre vivant ces comportements auprès de managers, de managers, de dirigeants, dirigeantes, et ensuite de réfléchir à quel autre problème on souhaite résoudre et comment dans chaque équipe on va pouvoir changer. Mais moi, ma réflexion, c'est toujours d'avoir une approche déjà d'incarnation auprès des managers, des manageuses et la direction, avant de commencer déjà à pointer le doigt les équipes en disant « vous devez changer ». Et je pense que c'est très puissant de voir ces managers, ces dirigeants, ou ces managers et ces dirigeants le changer. Au profit de quelque chose, pour le bénéfice de quelque chose, et te dire, ah ouais, ok, ça c'est assez motivant, et bien je vais l'incarner moi aussi, et aller, let's go. Donc c'est ça que j'essaye toujours de conseiller à des personnes qui sont dans cette situation-là.
Bruno:
Ce qui est rigolo c'est que ce que tu décris en fait c'est un peu le métier de développeur ou développeuse c'est qu'il faut qu'on en général les gens viennent nous voir en nous disant j'ai besoin de ça et nous la base de notre métier c'est de comprendre, certes ce dont ils ont besoin mais surtout quel problème ils cherchent à réellement résoudre, essayer de bien expliciter avec eux et de leur faire bien comprendre ce dont ils cherchent à résoudre comme problème, essayer d'expliciter avec eux tous les edge case tous les cas possibles et compagnie c'est exactement ce que tu as décrit c'est de la résolution de problème auprès des directions.
Denis:
À une échelle qui n'est pas forcément la même avec des contextes ou des métiers qui ne sont pas les mêmes mais ça reste de la résolution de problème et moi j'ai une approche assez banale de la résolution de problème qui est celle que tu viens d'expliquer.
Bruno:
Canon merci beaucoup Denis pour cette discussion j'aurais deux dernières questions pour toi, qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu tech ou non tech que tu souhaiterais partager avec l'ensemble des auditeuristes ?
Denis:
Oui, alors contenu, ou plutôt décontenu, moi je suis très inspiré par les relations, pardon, les sciences humaines et sociales, des quantités d'études qui sortent de recherches que je trouve extrêmement intéressantes, et j'invite tout le monde à s'y intéresser et pas avoir une approche uniquement technique de son métier. Et pour ça je fais un peu de l'auto-promo j'ai mon podcast qui s'appelle 0 virgule où j'interview des chercheurs et des chercheuses sur ces sujets et qui explique comment dans le travail on peut prendre en compte ces études là, pour réussir à s'améliorer à mieux travailler et à s'accomplir dans son travail et ensuite évidemment pour ne pas ne parler que de moi j'invite beaucoup à suivre, différents auteurs et différentes autrices je pense à Danielina je pense à Vincent de Goljac je pense à Maud Simonnet que j'ai évoqué tout à l'heure, à quantité d'autres chercheurs et chercheuses qui ont des points de vue je trouve très intéressants pour comprendre un petit peu le travail, ce qui fonctionne ce qui ne fonctionne pas qu'est-ce qui explique qu'on se sente bien ou pas bien dans une entreprise dans son métier.
Bruno:
On mettrait effectivement des liens en description et bien évidemment aussi vers ton podcast merci parce que je pense que les gens sont friands de genre de format. Et pour terminer, la question la plus importante de ce podcast, Denis, est-ce que tu es plutôt espace ou tabulation ?
Denis:
Plutôt espace.
Bruno:
Très bien. Merci beaucoup, Denis.
Denis:
Merci.
Bruno:
Et merci à tous d'avoir reçu cet épisode. Voilà, de l'agilité, je pense que vous le sentez au quotidien, c'est pas toujours parfait, c'est pas la solution idéale à tous les maux de l'entreprise. J'espère que cette discussion avec Denis vous a permis de mettre le doigt sur quelques éléments de réponse et d'amélioration de la situation. Il faut revenir aux fondamentaux, comme bien souvent, en fait, il faut revenir au manifeste de base et essayer de voir comment est-ce qu'on peut l'appliquer sans oublier cette philosophie principale. Je vous remercie aussi comme toujours de partager ce podcast autour de vous. N'hésitez pas à aller checker le Tipeee si vous souhaitez contribuer à ce podcast. Comme cet épisode sera diffusé en début d'année, je vous souhaite une très bonne année 2026, tous mes voeux de réussite pour l'année qui se passe et j'espère que vos fins d'année se sont bien passés. Je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine et d'ici là, codez bien !
