Avant-propos
Le texte qui suit est la version française d’un billet de blog à thèse publié en 2015 par le programmeur américain Michael O’Church.
Je l’ai contacté pour le traduire et faire connaître ses arguments en France, où les méthodes Agile, et plus particulièrement Scrum, n’ont de cesse d’envahir les entreprises privées.
L’agilité est sans nul doute une bonne chose, et l’Agile Manifesto n’est pas forcément déraisonnable. Si on la compare à l’imposture logique qu’est Waterfall, la méthode Agile s’avère notablement supérieure. Pourtant, Agile telle qu’elle est pratiquée dans les faits et dans la majorité des cas est profondément nocive ; et dans un premier temps, il ne me semble pas qu’une dichotomie Agile/Waterfall ait jamais été nécessaire à quelque projet que ce soit.
Il existe une variante d’Agile, nommée Scrum, que j’ai vu détruire des entreprises, littéralement. Par « détruire », je ne veux pas dire «par la suite, la culture n’était plus si bonne que ça» ; je veux dire que l’action s’est effondrée de près de 90%, en moins de deux ans.
Qu’est-ce qu’Agile ?
Agile a grandi dans le monde du Web consulting, où elle avait une valeur toute trouvée : lorsqu’on avait à faire à des clients retors qui ne savent pas bien ce qu’ils veulent, deux options s’imposaient : la première était de manager le client ; de solidifier ses attentes, de facturer le travail de manière appropriée, et de maintenir une relation d’égalité plutôt que de soumission. La seconde était d’accepter le manque de cohérence du client (cela dit, beaucoup de designers n’ont tout simplement pas le choix) et d’orienter le travail autour des dysfonctionnements de ce coté là.
Les programmeurs ont tendance à ne pas être très bons en relation client. Nous sommes des gens littéraux, précis. Nous aimons les systèmes qui ont des comportements formellement définis. Travailler avec des personnes non techniques est encore plus difficile pour nous ; nous avons tendance à prendre chacune de leurs requêtes à la lettre, au lieu d’essayer de comprendre leur besoin réel. «Agile» telle que pratiquée en entreprise, empruntée à l’environnement du conseil, va beaucoup plus loin que ça, et feint de croire que les ingénieurs ne sont pas assez intelligents pour comprendre ce que souhaitent leurs clients en interne. Le travail se voit ainsi atomisé en «user stories» puis en «itérations», ce qui, bien souvent, réduit à néant tout sens d’accomplissement et tout espoir de vision à long terme sur le devenir de la production.
De manière générale, nous avons tendance à créer deux types de projets de développement : au sein même d’une entreprise, ou bien en tant que client, lorsqu’on décide de sous-traiter. Dans le premier cas, on recrute pour obtenir une expertise que l’on a pas. Dans le second, on se débarrasse de tout ce que l’on ne souhaite pas faire soi-même. Il est évident que si la première catégorie d’employés est respectée, l’autre ne l’est pas. Les agences de conseil mal gérées finissent souvent par se transformer en décharges à travail de piètre intérêt. Scrum semble avoir été taillée pour les carrosseries, dont les relations avec la clientèle sont si mal gérées qu’elles ont besoin de surveiller quotidiennement leurs employés, parce qu’ils sont transformés en dépotoirs destinés à recevoir une besogne sans cohérence professionnelle que personne ne veut faire (et qui n’est probablement pas si importante que ça, si l’on en croit la basse rémunération qui vient s’ajouter au manque de respect.)
Transparence ultra-violente
Il y a pas mal de trucs à la mode sur nos lieux de travail, capables de rendre une carrière de programmeur extrêmement peu attrayante, en particulier pour cette espèce de jeunes gens créatifs et malins dont nous allons avoir besoin pour pallier aux besoins de la prochaine génération.
Les open spaces en sont l’exemple le plus flagrant : ils sont anti-productifs ; il est pénible de s’y concentrer. Ils relèvent de l’anti-intellectualisme, dans la mesure où les salariés craignent d’y être pris entrain de lire des livres, ou simplement de réfléchir à ce sur quoi ils sont entrain de travailler. Quand vous forcez les gens à participer à un jeu parallèle dans lequel ils doivent paraître productifs, ils deviennent moins productifs. Les open spaces n’ont d’ailleurs même pas été conçus pour forcer la productivité dans une but premier : il s’agissait d’une question d’image à soigner. Les startups financées par le capital risque se devaient de rassurer leurs investisseurs : elles utilisèrent cette configuration de l’espace pour que leurs bureaux semblent animés, perpétuellement affairés. (Pour le dire de manière brutale, un programmeur travaillant en open space avait plus de valeur en tant que « mobilier » que pour le code qu’il produisait.) Par la suite, pour toute une variété de raisons culturelles, les open spaces sont devenus «jeunes» et «cools» ; et aujourd’hui, ils ont infecté le monde de l’entreprise en général.
Il est bien connu que les créatifs perdent toute créativité lorsqu’on leur demande de s’expliquer pendant qu’ils travaillent. C’est la même chose avec le développement d’applications. Les programmeurs doivent souvent travailler dans des environnements à transparence unilatérale. Ces méthodes Agile, si souvent mal appliquées, exigent d’eux qu’ils fournissent une visibilité humiliante sur leur emploi du temps et sur leur travail, sans bénéficier d’aucune réciprocité. Au lieu de plancher sur d’authentiques projets sur le long terme pour lesquels ils seraient en mesure de s’enthousiasmer, ils sont relégués à travailler sur des «user stories» atomisées, relevants du niveau de la simple fonctionnalité ; de la même manière, il leur est souvent refusé de s’atteler à des améliorations qui ne sauraient être associées avec des besoins business à court terme, immédiats, ayant souvent été évoqués par la direction. Cette variante d’Agile, pervertie mais communément utilisée, élimine les concepts de propriété, d’initiative, ou d’appartenance, et traite les programmeurs comme des composants standardisés et interchangeables.
Scrum est la pire méthodologies, avec ses ridicules «itérations» sur deux semaines. Elle introduit une anxiété non nécessaire, qui se matérialise dans les creux des micro-fluctuations de la productivité de chacun. Il n’existe aucune preuve que cette esbroufe permette de produire de manière plus rapide, ou dans une qualité supérieure, sur le long terme. Elle rend simplement les gens plus nerveux, plus préoccupés. Beaucoup pensent que Scrum est une bonne méthode parce qu’en l’appliquant «les gens travailleront plus vite».
Ça fait dix ans que je suis dans le développement informatique, j’ai été tour à tour manager, développeur, et…. c’est complètement faux.
Problèmes spécifiques à “Agile” et Scrum
1. L’ingénierie business-driven (ou dirigée par les affaires)
Agile est souvent considérée comme supérieure lorsque comparée avec «Waterfall». Qu’est-ce que Waterfall ?
Waterfall est, de manière tout à fait objective, une chose épouvantable. C’est un modèle type «le travail roule vers l’aval», dans lequel chaque niveau hiérarchique appartenant à une organisation place sur son assiette ce qu’il considère être le «truc marrant», avant de laisser les restes à ses subalternes. Les projets sont définis par la direction, le design assuré par les architectes, les deadlines fixées par les managers, l’implémentation réalisée par l’élite de l’infanterie (les programmeurs), enfin, les tests et le déploiement sont délégués à l’arrière-garde. C’est extrêmement dysfonctionnel. Quand les gens ont le sentiment que les décisions importantes ont déjà été prises, ils perdent toute motivation à donner le meilleur d’eux-mêmes.
Waterfall reproduit le modèle social d’une organisation dysfonctionnelle avec une hiérarchie définie. Bien souvent, Agile reproduit le modèle social d’une organisation dysfonctionnelle — sans hiérarchie clairement définie.
J’ai une opinion mitigée sur les titres tels que «Senior», «Principal» et autres appellations dans le genre. Certes, ces titres ont de l’importance, et personnellement, je n’accepterais pas un emploi en dessous du niveau de «Principal» ou bien de l’équivalent du niveau de directeur ; mais je déteste qu’ils aient cette importance. Quand on prend le temps de l’examiner, on réalise que Scrum est conçue pour retirer du crédit et de l’autonomie aux ingénieurs les plus compétents et les plus empreints de séniorité, qui se voient contraints d’adhérer à des processus fabriqués pour des débutants (ne travailler que sur des items présents dans le backlog, passer cinq à dix heures pas semaine en status meetings) qui auraient pu écrire leurs premières lignes de code tout juste le mois d’avant.
Tel un état communiste en situation d’échec qui nivèlerait les richesses en répandant la pauvreté, Scrum, dans sa forme la plus pure, rabaisse toute l’ingénierie au même niveau ; et si ce n’est jamais clairement énoncé, il est évident que ce dernier se trouve bien en dessous de celui des clients, qui disposent, eux, d’une totale autorité pour décider de ce sur quoi il faut travailler.
Agile, telle que bien souvent implémentée, démultiplie la fréquence du contrôle et des échanges, tout en n’offrant aucun pouvoir aux ingénieurs. C’est un pari perdu, puisque ça veut dire qu’ils ont plus de chances d’être harcelés ou sanctionnés quand les choses prennent plus de temps qu’elles ne le devraient, ou plutôt qu’elles ne semblaient devoir. Cela créé beaucoup d’anxiété et de précipitation, et finalement peu de ce qui compte vraiment, à savoir, une excellente production.
La Silicon Valley s’est plantée sur pas mal de choses, particulièrement ces dernières années, mais s’il y a un concept qu’elle a bien compris et appliqué, c’est celui des entreprises dirigées par l’ingénierie. Pour des ingénieurs, prendre la direction de toute une entreprise n’est pas forcément l’idéal, mais tout le monde profite du fait qu’ils dirigent au moins l’ingénierie et mettent en place leurs priorités : eux sont davantage satisfaits du travail qu’on leur assigne (ou, mieux encore, qu’ils s’assignent à eux-mêmes) et l’entreprise bénéficie d’une ingénierie de bien meilleure qualité.
Si votre entreprise est destinée à être business-driven, c’est très bien. Mais si vous voulez du talent, n’embauchez pas des ingénieurs à plein temps. Vous pourrez avoir les meilleurs en tant que consultants (à partir de 200$ de l’heure, et plus), mais pas comme des employés à plein temps ; pas dans une entreprise de ce type. Les meilleurs ingénieurs ambitionneront de travailler dans une entreprise où l’ingénierie donne le ton, où elle décide de ce sur quoi il faut travailler, sans avoir à se justifier à des «Scrum Masters», à des «Product Owners» ou à d’autres couches de management non technique.
En fin de compte, Agile (telle qu’elle est pratiquée) et Waterfall sont toutes deux des formes d’ingénierie business-driven, et c’est pour cette raison qu’elles ne sont bonnes ni à produire des applications de qualité, ni des employés heureux.
2. Juniorité terminale
Le développement d’applications a malheureusement créé une culture de la juniorité terminale, soutenant ainsi la conception (extrêmement fausse) que la programmation est un «truc de jeunes» — bien que les meilleurs ingénieurs soient rarement jeunes.
Le problème avec les itérations de deux semaines d’Agile (ou «sprints») et les «user stories», c’est qu’il n’y a pas de stratégie de sortie. Il n’existe aucune clause mentionnant que «nous n’aurons plus à travailler de cette façon dès que telle ou telle chose sera finie.» C’est là pour rester, pour toujours. L’ingénierie business-driven et les status meetings ne s’en iront jamais. L’architecture, la R&D et le développement de produits ne feront jamais partie du travail d’un programmeur, parce que ces choses n’entrent ni dans des «user stories» atomisées, ni dans un sprint de quinze jours.
Par conséquent, le type de projets que les programmeurs souhaiteraient s’approprier dès qu’ils sont assez expérimentés sont souvent laissés de coté parce qu’il est ennuyeux de les justifier en terme de valeur à court terme pour l’entreprise. L’excellence technique compte, mais il est pénible de devoir la vendre à ceux qui ont assurément décidé de ne pas en être convaincus.
L’un des product managers d’une entreprise dans laquelle je travaillais a dit un jour que la différence entre un ingénieur sénior et un ingénieur junior était la capacité à fournir une estimation de temps précise. Heu, non. Dire chose pareille est insultant, en fait. Je déteste les estimations, parce qu’elles génèrent de la politique, et ne font pas en sorte que les choses se fassent mieux ou plus vite (en réalité, c’est même le contraire qui se produit.)
La pire des choses au sujet des estimations, c’est qu’elles poussent une entreprise à faire uniquement ce qui peut être estimé. Ainsi, les programmeurs privilégient les tâches faciles et à faible rendement, mais sûres, et dont l’entreprise n’a en réalité pas besoin (même si le middle management pense différemment.) Tout ce qui vaut vraiment le coup d’être fait a toujours une chance d’échouer, et comporte trop d’inconnues pour qu’une tentative d’estimation s’avère utile. Le focus d’Agile sur la valeur à court terme finit par éloigner les employés du type de travail dont une entreprise a besoin en réalité : c’est la réputation de chaque programmeur, et leur aptitude à manager leur temps, qui passe au premier plan.
Ce que cette culture nous raconte, c’est que la programmation est une chose infantile, à mettre de coté dès que l’on atteint l’âge de 35 ans. Je ne suis pas d’accord avec cette mentalité. Je pense qu’elle est nocive, en réalité. Je suis dans la première moitié de la trentaine, et j’ai l’impression d’à peine commencer à être bon en programmation. C’est une idée terrible que de chasser les aînés seulement parce qu’ils sont assez expérimentés pour savoir que «Agile» et Scrum n’ont rien à voir avec l’informatique et n’apportent aucune valeur ajoutée.
3. C’est bêtement, dramatiquement “court terme”
Agile a été conçu par et pour les agences de conseil marginales. Autrement dit, pour des entreprises qui n’ont pas la crédibilité qui leur permettrait de négocier d’égal à égal avec leurs clients ; en proie à des deadlines serrées tandis que chaque projet comporte un risque existentiel en clientèle. C’est un truc pour les fauchés qui essaient de percer. Mais voilà le problème. Scrum est souvent mise en place dans les grandes entreprises et les startups financées. Les gens qui rejoignent ces sociétés ne veulent pas être défavorisés. Ils veulent de la sécurité. C’est pour cette raison qu’ils sont salariés, au lieu de créer leur propre boite. Personne ne souhaite jouer un rôle d’arrière-plan à moins d’y trouver intérêt personnel important. «Agile» dans une entreprise signifie de la souffrance et du danger, sans aucune récompense.
Quand chaque projet chez le client représente un risque existentiel ou réputationnel, Agile peut-être la bonne façon d’opérer, parce qu’un focus sur des itérations à court terme devient utile lorsqu’une entreprise est menacée, et que le concept même de “long terme” n’a pas lieu d’être évoqué. En cas d’urgence, un management de projet agressif prend du sens. Il n’en a aucun en tant qu’arrangement permanent ; tout du moins pas pour les développeurs talentueux qui auront toujours accès a des options plus agréables et moins stressantes.
Sous Agile, la dette technique s’accumule, et elle n’est pas adressée parce que les commerciaux, qui font la pluie et le beau temps, ne verront pas les problèmes avant qu’ils ne soit trop tard, ou du moins, avant que la résolution de ces problèmes n’atteigne des coûts beaucoup trop élevés. En outre, les ingénieurs sont récompensés ou punis de manière individuelle, et uniquement en fonction du spectre du «sprint» de quinze jours en cours, ce qui veut dire que personne ne regarde jamais à cinq «sprints» dans le futur. Agile ne fait que déployer des «sprints» myopes et idiots, les uns après les autres : pas d’améliorations, pas de progrès, ce n’est que bug après bug, ticket après ticket, que le travail se fait.
Si les gens qui savent se satisfaire de mélanger tout et n’importe quoi dans leur carrière peuvent travailler de cette manière, les ingénieurs conscient de leur valeur détestent se pointer au boulot un lundi matin sans savoir ce sur quoi ils vont travailler.
4. Agile n’a aucun respect pour la cohérence professionnelle
Les « user stories » atomisées sont catastrophiques pour la carrière d’un ingénieur. Quand arrive la trentaine, vous êtes supposés être capable de montrer que vous pouvez travailler au niveau projet, et que vous êtes prêt à dépasser ce niveau pour penser en terme d’infrastructure, d’architecture, de leadership.
En cas d’urgence, que ce soit dans une agence de conseil luttant pour apaiser un client important, ou dans la salle de guerre d’une entreprise, la cohérence de carrière peut attendre. Rares sont les employés qui vont refuser deux semaines de besogne désagréable ou incohérente sur le plan professionnel si elle est réellement nécessaire pour le bien de leur boite. L’importance du travail créé les avantages de carrière. Si vous pouvez dire «j’étais dans la war room et je parlais 20 minutes par jour avec le CEO», ça passe mieux d’avoir fait le sale boulot.
Toutefois, quand il n’y a pas d’urgence, les programmeurs apprécient que leur évolution de carrière soit prise au sérieux ; ils quitteront l’entreprise si ça n’est pas le cas. Dire «je faisais partie d’une équipe Scrum» signifie «malmenez-moi». Se taper le sale boulot parce que le CEO a admit qu’une tâche désagréable apporterait des millions de dollars de plus-value (et qu’il la récompenserait en conséquence) est une chose ; accepter de faire un travail ingrat parce qu’on vous a assigné des « user stories » et des tickets Jira montre juste qu’on vous prenait pour un tocard.
5. Le but est d’identifier les mauvais éléments, mais le taux de faux positifs est bien trop élevé
Scrum est vendu comme un process pour «éliminer les obstacles», ce qui est une jolie façon de dire «identifier les branleurs». Le problème, c’est qu’il créé plus de mauvais éléments qu’il n’en chasse. C’est un état de surveillance qui requiert de chaque ingénieur qu’il fournisse une visibilité hautement granulaire sur son travail individuel et sur son taux de productivité.
Il y a un faux débat sur nos libertés civiles : l’argument du «rien à cacher». Certaines aiment à pérorer que l’invasion de la vie privée — disons, par l’application des lois — n’est pas un problème dans leur cas, parce qu’ils ne sont pas des criminels. Nous ratons ici quelques points clés. Par exemple, le fait que la loi peut changer. Allez donc en parler à ceux qui étaient juifs dans l’Europe Centrale des années 30. Même pour les gens respectables, un état de surveillance est un état d’anxiété.
Le fait d’être observé change la façon dont les gens travaillent. Dans les métiers créatifs, c’est catastrophique. Il est impossible de travailler de manière créative si l’on doit quotidiennement se justifier.
Un autre problème qui vient à l’esprit est la sensibilité au statut. Les programmeurs aiment penser qu’ils ont transcendé quelques millions d’années d’évolution primale liée au statut social, mais le fait est que le statut social compte, et ce n’est pas se montrer réac’ que de le reconnaitre. Les gens plus âgés, les femmes, les minorités raciales, et les personnes handicapées ont tendance à être plus sensible à leur statut social, parce qu’en ce qui les concerne, c’est une question de survie. Une surveillance constante du travail de quelqu’un démontre un manque de confiance, et associe celui qui est surveillé à un faible statut social. Les plus sensibles à ce statut sont les premiers à être sur le déclin quand la surveillance s’accroît (y compris quand ils sont les meilleurs employés.) S’ils sentent qu’on ne leur fait pas confiance (et quel autre sentiment pourrait être transmis par une culture qui attend que chaque tâche soit justifiée ?), alors ils perdent rapidement toute motivation.
Agile, et plus particulièrement Scrum, exploitent le faux débat du rien-à-cacher. À moins d’être un «mauvais élément», (ça vous botte, une chasse aux sorcières ?) vous ne devriez pas être ennuyé par un status meeting quotidien, n’est-ce pas ? Les seules personnes qui ont à redire quand au fait de justifier de leur travail en terme de valeur à court terme pour l’entreprise sont des branleurs qui veulent voler de l’argent à leur patron, pas vrai ? Bien évidemment que non.
La culture de la transparence ultra-violente est conçue pour les personnes les moins sensibles au statut social : les hommes, jeunes, blancs ou asiatiques, privilégiés, sans handicap, et n’ayant pas encore été testés, challengés, ou victimes de burn-out au travail. Elle est faite pour ceux qui pensent que les ressources humaines et le management sont une perte de temps, et que les employés devraient juste faire avec le fait d’être diminués ou insultés.
Bien souvent, ce sont les meilleurs éléments qui souffrent le plus après l’adoption d’Agile et de Scrum, parce que la R&D se voit éliminée avec efficacité, et que l’obsession des «itérations» à court terme, ou «sprints», signifie que la possibilité d’essayer quelque chose qui aurait ne serait-ce qu’une seule chance d’échouer n’existe plus.
La vérité sur les mauvais éléments, c’est qu’on a pas besoin d’«Agile» pour les identifier. Tout le monde sait qui ils sont. La raison pour laquelle certaines équipes se trainent des personnes désengagées, toxiques ou incompétentes, c’est que personne ne fait rien à leur sujet. C’est un problème de management des personnes, pas d’organisation du travail.
6. Un changement de perception malheureux
Il semblerait qu’on ait la preuve qu’un management agressif soit capable de transformer des employés pas spécialement compétents en employés à peu près utiles. J’appelle ça le «Whisky Goggles Effect» : il transforme les 3 en 4 et les 4 en 5, mais vous rend tellement inattentif et négligent que les 7 et les 9 ne veulent plus avoir à faire à vous. Incapables de voir leur créativité irriguer un système dans lequel tout doit être justifié en terme de valeur à court terme, les meilleurs programmeurs s’en vont.
Du point de vue d’un manager qui ignore comment fonctionne une application, ça peut sembler être un deal acceptable : quelques excellents programmeurs, de niveau 7 et plus donnent leur démission après l’arrivée de Scrum ; en contrepartie de quoi, la foule des 3 et 4 se peuple soudainement de 5 acceptables. Le problème est que la différence entre un programmeur de niveau 7 et un programmeur de niveau 5 est beaucoup plus importante que la différence entre un programmeur de niveau 5 et un programmeur de niveau 3. Si vous perdez vos meilleurs éléments et vos leaders (qui ne sont pas forcément dans des rôles définis de leadership), alors la petite amélioration que vous percevrez chez les moins compétents, pour qui Scrum a été conçue, n’aboutira sur rien de bon.
Scrum et Agile génèrent ce que j’appelle un biais dans les avantages liés au statut. Beaucoup de personnes mesurent leurs échecs ou leurs succès non pas de manière objective, mais en jaugeant l’ascension de leur statut au sein d”une organisation. Mettons que la valeur sur le marché d’un programmeur de niveau «3» soit de $50,0000 par an, et que celle d’un programmeur de niveau «5» soit de $80,0000 par an. (En réalité, les salaires des programmeurs ne suivent pas cette échelle ; je connais des 3 à $200,000 et des 7 à moins de $70,000, mais ignorons cela.) Convaincre un programmeur de niveau 5 d’accepter le salaire d’un niveau 3 (en échange d’équité de startup !) s’entend, psychologiquement, non pas comme un profit de $30,000 (ce qui ne représente rien) mais comme un profit de 2 points.
Agile, Scrum, et de manière plus générale la culture de la discrimination basée sur l’âge, ont pour but d’obtenir les “profits de statut” les plus extraordinaires, plutôt que de générer des profits économiques qui seraient obtenus, de manière plus classique, en embauchant les gens qui apportent le plus de valeur (même si vous les embauchez 50% au dessus des prix du marché, parce que les meilleurs programmeurs valent 10 à 30 fois leur valeur sur le marché.)
Les personnes les moins informées de la valeur de leur statut social sont les jeunes. Vous trouverez des gens de 22 ans de niveau 6 qui pensent qu’ils sont des 3, et vous les soumettrez à Scrum. Mais les 9 de 50 ans savent probablement qu’ils sont des 9. Ils accepterons peut-être, à contrecœur, les conditions de travail d’un 8.5, mais ils n’accepterons pas de retomber à 3, ni même à 6. Rechercher le profit de statut est bien sûr inutile ; on réussi en affaires en gagnant plus d’argent que l’on en dépense ; pas en «tirant» sur le niveau ou le statut de chacun. Il existe peut-être toute une industrie qui embauche des ingénieurs de niveau 5 pour les traiter (et les payer) comme des 4. Pourtant, dans les conditions actuelles du marché, il est beaucoup plus profitable d’embaucher des 8 et de les traiter comme des 8.
7. C’est vendu de façon malhonnête
Pour couvrir ce point, je vais me concentrer sur Scrum. Certaines personnes assurent que Scrum est «l’Agile extrême», et d’autres disent que c’est la variante la moins agile d’Agile. (Ceci dénote peut-être un problème ; il semble compliqué de s’entendre sur ce qui est ou n’est pas «Agile».)
Une méthode comme Scrum a bien sa place : une place temporaire, limitée dans le temps. Le mensonge que l’on vend étant que ça fonctionne de partout, et en tant qu’arrangement permanent.
Ce pourquoi Scrum fonctionne
Avant que la mode d’Agile n’en fasse un process permanent, «Scrum» était un terme parfois utilisé dans le cadre de ce que les entreprises peuvent aussi appeler un «Code Rouge» ou une «Urgence de Salle de Guerre». Dans le cas d’un problème imprévu, et en évolution rapide, vous convoqueriez vos meilleurs éléments pour former une équipe transversale.
Cette équipe n’avait pas de manager défini, alors vous désigneriez un leader (un «Scrum Master») et lui octroieriez l’autorité. Vous voudriez qu’il ne soit pas un manager en tant que tel (puisqu’il se devrait d’être aussi impartial que possible.) Étant donné qu’il s’agit d’une crise à court terme, les objectifs de carrière individuels seraient être mis de coté pour un temps. La période à venir serait considérée comme un «sprint», parce qu’il serait attendu des employés qu’ils travaillent aussi vite que possible pour régler le problème, et parce qu’ils seraient capables de retrouver leur travail et leur rythme habituels une fois le problème réglé. De la même manière, lors de telles urgences, il serait bienvenu de préciser que personne ne sera évalué individuellement. Le focus est la mission, et seulement la mission.
Quand vous imposez un process et demandez une transparence unilatérale à tous vos employés, les gens se sentent surveillés. Ils prennent conscience qu’ils sont traqués, et qu’ils seront étiquettés comme «mauvais éléments» dès que leur fluctuation hebdomadaire individuelle courbera du mauvais coté. Alors, ils seront contrariés. C’est dysfonctionnel. De la même manière, quand vous montez une équipe de bons éléments pour gérer une crise bien spécifique et limitée dans le temps, ils n’auront pas de problème à fournir des status updates fréquentes, à partir du moment où ils savent que cela relève de l’exigence extraordinaire de la situation, plutôt que de la pauvreté de leur statut social.
Deux scénarios devraient venir à l’esprit : le premier est un groupe d’individus spécifiques (à l’exception des hauts dirigeants) passant maximum quatre semaines par an à travailler dans la war room d’une entreprise (s’il y passent plus de temps, c’est qu‘il y a un problème : les urgences devraient être plus rares.) Le second est un cabinet de conseil rencontrant des problèmes pour s’établir, peinant à manager ses clients, à se construire une réputation indépendante, et qui sera forcé d’opérer dans un état d’urgence permanent.
Deux problèmes
Scrum, de cette manière, reconnait l’idée qu’on doit parfois user du pouvoir de l’urgence pour prendre à parti les leaders, qui feront ce qu’ils estiment nécessaire pour qu’une tâche soit accomplie, remettant le débat à plus tard. Et c’est très bien. Parfois, c’est ainsi que les choses doivent être faites.
Le traditionnel problème du pouvoir de l’urgence est que bien souvent, il est là pour rester. Dans bien des circonstances, ceux qui prennent le pouvoir par l’urgence voient bien des avantages à la prolonger. C’est assurément un problème de management. Le dysfonctionnement et l’urgence requièrent plus d’efforts managériaux qu’une société bien dirigée en temps de paix. La résultante étant que bien des managers, et plus particulièrement dans la technologie, recherchent des opportunités d’urgences, et le pouvoir de l’urgence.
Il est aussi plus gratifiant pour un apprenti démagogue (un «Scrum Master») d’être perçu comme un «tueur de dragons» plutôt que d’éviter d’attirer les dragons jusqu’au village en premier lieu. Le problème de l’acharnement de Scrum sur l’ingénierie business-driven est qu’il transforme en vertu («la collaboration client») le fait d’attirer et de tuer les dragons (les «exigences client») quand il serait peut-être plus prudent de ne pas les faire sortir de leur grotte en premier lieu.
«Agile» et Scrum glorifient l’urgence. C’est leur premier problème. Elles sont une réinvention de ce que l’industrie du jeu vidéo appelle le «crunch». Travailler de cette façon n’est pas viable. Un focus agressif sur les performances individuelles, une inconséquence quand aux objectifs de carrière de chacun lors de l’assignation du travail, et un mandat qui établit que les employés travailleront seulement sur les tâches les plus hautement priorisées ; tout cela confère beaucoup de de valeur à l’urgence, mais devient toxique et démoralisant sur le long terme. On peut tolérer une perte d’autonomie à court terme, mais seulement dans le cas où on aura défini au préalable le moment où l’autonomie sera restaurée.
Le second problème est que ces pratiques sont vendues de manière malhonnête. Il y a toute une industrie de petites agences qui ont grandit en expliquant à des entreprises comment être «Agile» en développant des applications. Le problème est que ces idées ne sont pas nouvelles. La terminologie est neuve, mes les concepts sont pour la plupart empruntés à un «management scientifique» périmé, et en échec (qui était loin d’être «scientifique», et n’avait pas fonctionné.) Encore une fois, ces méthodes fonctionnent de temps à autres pour frapper des cibles bien définies dans des circonstances d’urgence, mais le perma-scrum est un naufrage assuré.
Si les bons et les mauvais aspects d’«Agile» étaient adressés, alors je n’aurais pas un problème aussi grave avec le concept. Quand une entreprise pourvue d’une équipe de développeurs juniors a besoin de livrer des fonctionnalités rapidement, elle peut considérer l’usage de ces méthodes pour une courte période, tout en gardant en tête de les éliminer au fur et à mesure que son effectif grandit et que ses délais de livraison pardonnent davantage. Si Scrum était vendue pour ce qu’elle est — soit un ensemble de mesures d’urgence ne pouvant être utilisées pour améliorer la productivité de manière permanente — il y aurait beaucoup moins de monde pour l’acheter, et l’industrie du conseil «Agile» n’aurait pas lieu d’exister. Il a fallu une représentation malhonnête de ces méthodes (glorification du «crunch» et des fixs permanents) pour qu’elles puissent être commercialisées au monde de l’entreprise dans son ensemble.
Perspectives d’avenir
Il est temps, pour cette culture de juniorité terminale, de faible autonomie, et de management agressif, de disparaître. Elle n’est pas qu’un lot de mauvaises idées. Elle est bien plus dangereuse que ça, parce que toute une génération d’ingénieurs va l’absorber, sans jamais avoir connu un monde meilleur. Beaucoup trop de jeunes programmeurs sont condamnés à la médiocrité à cause de cette idée que l’ingénierie business-driven et les «user stories», c’est ce qu’on a toujours fait. Ceci doit être empêché ; l’intégrité future de notre industrie pourrait bien en déprendre. «Agile», dans chacune de ses implémentations dégénérées, est un puits d’absurdité qui n’a rien à voir avec la programmation, encore moins avec l’informatique. L’ingénierie business-driven, de manière générale, est un cul-de-sac. Elle doit être renvoyée au fond de la vase d’où elle est née.
