Un gros business

L’ « Agile1 » est devenu un gros business. Lancé, sans l’ombre d’un doute, par le succès qu’a pu rencontrer par la Scrum Alliance avec l’offre de formation certifiante de ScrumMaster. À aujourd’hui, nous voyons des centaines, peut être des milliers de soit-disant formateurs et coachs « Agile », ainsi que plusieurs cadres de travail et méthodes en concurrence. Nous voyons aussi des formations en leadership agile, en gestion de projets « Agile », et ainsi de suite.

Bon pour l'entreprise

Toutefois, certaines de ces offres, voire la plupart ne sont pas mauvaises, du moins pour l’entreprise. Les organisations qui essayent de s’améliorer généralement s’améliorent, et même si les idées « Agile » sont appliquées de manière médiocre, le simple fait d’essayer apporte toujours ou presque toujours quelque chose de positif à l’organisation. L’organisation devrait bénéficier d’une meilleure visibilité sur ce qu’il se passe, et ce qui conduit le plus souvent, même pour le management le moins éclairé, à prendre de meilleurs décisions. C’est quelque chose de bien, et je suis entièrement d’accord avec ça.

Pas si bon que ça pour les développeurs

L’image n’est pas aussi bonne que ça pour les développeurs, en fait pour toutes les personnes impliquées dans la réalisation des produits que les entreprises « Agile » font. Lorsque les idées « Agile » sont appliquées de manière médiocre, cela conduit le plus souvent à davantage d’interférences avec les développeurs, à moins de temps à faire le travail, à davantage de pression et à « aller plus vite ». C’est mauvais pour les développeurs, et, en dernier ressort, mauvais pour l’entreprise aussi, parce que faire de l’« Agile » de manière médiocre aura comme résultat, le plus souvent, d’obtenir davantage d’anomalies et d’avancer beaucoup plus lentement que ce qu’il aurait été droit d’espérer atteindre. Le plus souvent, les bons développeurs quittent ce type d’organisation, ce qui a comme conséquence une entreprise encore moins efficace qu’avant la mise en place d’« Agile ».

Ma réflexion vient de ce qu’a dit Kent Beck il y a dix ans. J’aimerais que le monde soit plus sûr pour les développeurs. Au fond de moi, je suis un développeur, malgré toutes ces années de management, de consulting et d’écriture. J’ai fait du code un peu plus tôt dans la journée et j’en fais toutes les semaines si ce n’est tous les jours. Cela me fend donc le cœur de voir les idées que nous avons écrites dans le Manifeste Agile utilisées pour rendre la vie des développeurs pire, plutôt que meilleur. Cela m’attriste aussi que l’entreprise ne puisse en tirer ce qu’elle pourrait, mais mon soucis principal est avant tout les personnes qui font le boulot.

Safe, pas SAFe 2

Depuis quelques années, j’entends plusieurs développeurs qui disent qu’« Agile » c’est de la merde. (Ils disent généralement que « Scrum » c’est de la merde, parce que la plupart des gens dans les organisations qui essayent de faire de l’« Agile » essayent de faire en fait du Scrum). J’essaye d’aider ces personnes à comprendre que leur organisation font mal de l’« Agile » : ces organisations ne font pas ce que les auteurs du Manifeste recommandent, ce que Scrum recommandent, ce que les experts en développement agile de logiciels recommandent. Mon espoir est que les personnes et leur organisation, qui entendent ma voix puissent s’en sortir et se rapprocher des idées authentiques qui se cachent derrière le Manifeste Agile et s’éloignent de ces formes de Faux Agile ou de Dark Agile que nous voyons autour de nous.

Ça ne marche pas vraiment. Des initiatives comme des formations « avancées » Scrum, des certifications et des initiatives orientées sur le leadership sont de bonnes initiatives, et pourraient porter leurs fruits au fil du temps, mais au mieux elles mettent du temps à avancer et peuvent ne jamais arriver jusqu’au pauvres développeurs qui travaillent au fond de la mine.

Il est temps d’essayer quelque chose de nouveau, et voici ce que c’est :

Les développeurs devraient abandonner l’« Agile »

Bien entendu, les développeurs vont continuer à se retrouver à travailler dans un environnement Scrum, ou dans des organisations qui utilisent SAFe. Certains peuvent même être amenés à rencontrer des approches « Agile » comme « DAD », ou, s’ils sont chanceux, des approches plus éclairées comme « Modern Agile », ou « Heart of Agile ». Certains peuvent être suffisamment chanceux pour se retrouver à faire de l’Extreme Programming que l’on appele également « Le Scrum qui fonctionne vraiment »

Se détacher des méthodes ayant un nom

Quoi qu’il en soit, je crois que les développeurs devraient détacher leur façon de penser de toute méthode « Agile » ayant un nom. À la place, ils devraient tourner leur attention et leurs facultés d’apprentissage vers des manières de faire du développement logiciel qui marchent au sein même de ces méthodes « Agile ». Ces approches de développement, pour moi, impliquent l’utilisation de pratiques telles que, sans y être limité, celles d’Extreme Programming. Plus généralement, le travail du développeur devrait adhérer aux principes fondamentaux qui sous-tendent le développement agile de logiciels, tels que nous les avions à l’esprit lorsque nous avons écrit le Manifeste. Aujourd’hui, je résume les idées de cette manière :

Peu importe quel cadre de travail ou méthode votre management pense appliquer, apprenez à travailler de cette manière :

  • Produisez un logiciel fonctionnel, testé, opérationnel, intégré toutes les deux semaines, toutes les semaines. Renforcez vos compétences jusqu’à que vous soyez capable de créer une nouvelle version opérationnelle chaque jour, deux fois par jour, plusieurs fois par jour.

  • Gardez une conception propre du logiciel. Au fur et à mesure qu’il grandit, la conception aura tendance à devenir complexe et bordélique. Résistez et inversez volontairement cette tendance, refactorez par petites étapes en continu, tout le temps, afin que votre rythme de progression soit aussi stable et régulier que possible.

  • Utilisez l’incrément actuel du logiciel sur lequel vous baserez toutes vos discussions avec le management et les responsables produit. Parlez en terme de ce qui est prêt à être livré, et en terme de ce qu’ils aimeraient que vous fassiez par la suite.

Il s’agit du meilleur espoir de l’équipe de développement pour avoir une vie convenable. En gardant en état prêt-à-livrer du logiciel, nous pouvons atteindre n’importe quelle date butoir avec le meilleur résultat possible. « Est-ce que c’est aujourd’hui la date butoir ? Voici ce que nous avons et c’est prêt à livrer. »

Au fur et mesure que nous approchons de la date butoir, et que nous négocions sur quoi faire ensuite, le logiciel qui fonctionne actuellement dans nos mains nous permet de faire en sorte que la discussion reste concentrée sur la suite, qui est la chose la plus importante à faire, plutôt que sur une liste quasi-infinie de choses qu’ils pensent vouloir. Ce n’est pas facile de changer d’un point de vue de « faire tout ceci » à « faire ceci ensuite », mais il s’agit de notre meilleure chance pour avoir une vie convenable, et il s’avère souvent possible de changer de point de vue, car nous travaillons à collaborer avec nos dirigeants plutôt que de travailler sous leurs ordres.

Dans le cadre d’une approche imposée

Trop souvent, l’approche « Agile » utilisée par une équipe est imposée. Les méthodes « Agile » à grande échelle semblent recommander carrément l’imposition du processus. Lorsque je parle de ce type de méthodes, j’inclus la méthode soit-disante « SAFe »2, Scaled Scrum et LeSS parmi tant d’autres. Elles sont généralement présentées à l’entreprise, et on s’attend à ce que l’entreprise les « installe », ou les « initie ».

En tant que développeur, vous pouvez être certain que ce lancement ne se passera pas en douceur ni de manière vraiment Agile. Il y a de grandes chances que vous n’aurez pas de formation, encore moins éduqué, encore moins avoir une vraie aide pour faire votre boulot. Vos dirigeants auront peut être reçu une formation, peut-être même une semaine entière (!), pour les préparer à apporter ce changement drastique dans l’approche de l’organisation par rapport au produit et au développement logiciel. La route risque d’être un peu chaotique.

Un vrai logiciel est notre seul espoir - Leia (communication secrète)

Mais si vous pouvez de manière fiable sélectionner du travail à faire au cours d’un « Sprint » ou d’un « wagon de marchandises »3 ou quel que soit la dénomination donnée à la période de temps par le conducteur du train de livraison, et faire ce boulot, rassemblé le tout dans une nouvelle version du système fonctionnelle, testée, intégrée, prête à être livrée, vous serez préparé à faire au mieux tout ce qui est possible d’être fait.

Ralentissez pour livrer

Si vous n’êtes pas en capacité de gérer cela, je vous conseille de prendre en charge moins de travail à chaque période de temps, jusqu’à que vous ayez pris un lot de travail suffisamment petit que vous pouvez réellement terminer. Cela sera dificile ! Les gens vous pousseront à « aller plus vite ». Faites de votre mieux ! Sous la pression pour signer à faire plus que vous n’êtes en capacité, je vous suggère que vous travailler sur un ou deux items, de les terminer complètement - complètement empaqueté, testé et opérationnel - et puis faites-en un autre, de telle manière qu’à la fin du wagon vous ayez quelque chose que vous puissiez de manière absolue dire c’est terminé. Prenez cette décision irrémédiable de ne pas tout faire, et d’essayer d’orienter les plannings et les attentes à partir de la réalité, non à partir de la fantaisie de ce qui était demandé, et que vous n’auriez jamais eu de toute façon la chance de pouvoir terminer.

Cela ne sera pas parfait, et du moins pour un temps, ça ne sera pas tout rose. Il s’agit simplement de la meilleure chance de survie en bas de cette mine que je puisse connaître. Avoir une tranche du produit complètement opérationnelle est la meilleure manière pour retourner la situation que je puisse connaître. En cas de mauvaise situation, tout ce que nous pouvons faire c’est de faire de notre mieux, et d’essayer de faire en sorte que les choses aillent mieux.

Très clairement, dans une organisation plus éclairée, ou dans une organisation qui apprend de manière continue, on sera de plus en plus ouverts aux vraies idées du Manifeste Agile. La vie peut s’améliorer, et j’espère qu’elle le sera.

J’ai été dans ce genre de situations, et plutôt que partir, le mieux que je connaisse c’est de faire du bon boulot, de le rendre visible, opérationnel, testé et intégré et d’aider les personnes à voir la réalité.

Choisir une approche

Le Manifeste appelle à avoir des équipes « auto-organisées », et dans le meilleur des cas, cela se matérialise en laissant l’équipe choisir son propre processus. Si je devais lancer une entreprise, je laisserais les équipes choisir le processus de leur choix.

Je demanderais des résultats, non un processus spécifique

Toutefois, il devrait y avoir des contraintes, non pas sur la manière dont elles choisissent de travailler, mais ce sur quoi j’ai besoin d’avoir de la visibilité. J’indiquerais clairement qu’environ toutes les deux semaines, j’aimerais voir une tranche de leur produit testé et opérationnel. Elles me montreraient ce qu’elles ont pu prévoir de construire, et ce qu’elles ont construit. Cette tranche devrait être vraiment opérationnel et inclure des capacités visibles que je serais en mesure de comprendre. Nous parlerions de ce qu’elles devraient faire lors de l’intervalle suivant. Et j’indiquerais clairement qu’une semaine serait mieux que deux, et qu’une journée serait mieux qu’une semaine.

J'offrirais mon aide

Je leur offrirais mon aide. J’offrirais aux gens une connexion stable avec les besoins du métier à concrétiser par le produit, ce qui devrait les aider à décider quelle tranche de travail à faire par la suite. J’offrirais un accès à des formations et à du support pour faire le boulot qu’elles doivent faire. Je ferais en sorte d’être sûr qu’elles soient équipées pour faire ce que je leur demande de faire.

Bien sûr, je ferais cela parce que je sais la manière de faire ce genre de boulot. Vous pourriez être suffisamment chanceux si vous étiez dans une situation similaire à celle-ci, tout du moins jusqu’au moment où vous pouvez choisir votre propre processus.

Chhut. Peut-être XP !

Si vous avez la chance de choisir, je recommanderais que vous commenciez par quelque chose comme Extreme Programming (XP). XP contient tout ce dont vous avez besoin en terme de planification, de circuits de retours d’informations, et qui comprend les pratiques techniques de base dont vous avez besoin pour faire ce dont nous avons pu parler jusqu’à présent ici, et de faire ce que j’aurais pu demander.

Et je recommanderais que vous restiez alerte en permanence quant aux signes concernant toutes les autres choses dont vous pourriez avoir besoin. « ATDD, TDD et refactoring » sont des choses qui, à mon avis, vous pourriez avoir besoin jusqu’à ce que vous connaissiez quelque chose de mieux. Mais il y a des dizaines, des centaines, des milliers d’autres choses que vous auriez besoin aussi. Restez alerte à leurs égards, et lorsque vous les aurez identifiées, appropriez-les vous.

Atteindre l’excellence dans la construction logicielle est l’activité d’une vie. Même Extreme Programming, la meilleure approche officiellement nommée que je connaisse, ne fait qu’effleurer la surface. Aller vers cette excellence dépend de votre équipe et de ses membres.

En résumé

À part peut-être une orientation personnelle vers les idées d’Extreme Programming - en tant qu’espace d’idées plutôt qu’en tant que méthode - j’en viens vraiment à penser que les développeurs de toutes sortes devraient n’avoir aucun attachement particulier envers aucune méthode « Agile » que ce soit. De la manière dont ces méthodes se manifestent sur le terrain, elles sont bien trop souvent l’ennemi du bon développement logiciel plutôt que son ami.

Toutefois, les valeurs et les principes du Manifeste pour le développement agile de logiciel continue à offrir la meilleure manière que je connaisse pour réaliser des logiciels. Basé aussi sur mon expérience longue et variée, j’embrasse ces valeurs et ces principes peu importe la méthode qui peut-être suivi par une grande organisation.

Il s’agit de mon opinion que je vous offre ici comme d’un conseil. Faites-en ce que vous voulez selon ce qui vous conviendra le mieux.


Auteur : Ron Jeffries
Source : Developers Should Abandon Agile
Date de parution originale : 10 Mai 2018


Traducteur : Nicolas Mereaux
Date de traduction : 26/04/2019


Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.


  1. Dans le présent article et ailleurs, j’utilise le mot entre guillemets « Agile » pour faire référence aux différentes instances, approches et processus qui utilisent le mot « Agile » pour se qualifier eux-mêmes d’agile, mais sans nécessairement adhérer ni à la lettre ni à l’esprit du développement agile de logiciels que nous avons écrit dans le Manifeste Agile. Je ferai référence quelques fois au « Faux Agile » ou au « Dark Agile » pour mettre l’accent dessus et décrire les soit-disantes approches « Agile » qui sont sur la mauvaise voie. Je peux aussi faire référence au « Manifeste Agile » et plus particulièrement aux idées fondamentales du Manifeste auxquelles je continue de croire. 

  2. Safe, not SAFe - jeu de mots impossible à rendre en l’état. L’auteur joue le mot Safe signifiant sécurité, sain et sauf avec l’acronyme de l’approche SAFe (Scaled Agile Famework) - NdT 

  3. Allusion de l’auteur à ce que l’on appelle un train SAFe ; un train SAFe étant grosso modo un ensemble de travaux développés par différentes équipes et qui sera livré régulièrement à une date précise - NdT