Cela me brise le cœur de voir les idées que nous avons écrites dans le Manifeste Agile être utilisées pour aggraver la vie des développeurs, au lieu de l'améliorer" déplore un des co-auteurs du Manifeste Agile de 2001.

Quand l'un des co-auteurs du Manifeste Agile appelle les développeurs à fuir les initiatives de développement agiles, vous devinez alors que l'intention de départ a été dévoyée.

"Cela me brise le cœur de voir les idées que nous avons écrites dans le Manifeste Agile être utilisées pour aggraver la vie des développeurs au lieu de l'améliorer" déplore Ron Jeffries, co-créateur de la méthodologie Extreme Programming (XP) et défenseur de longue date des pratiques de développement.

Les développeurs dans une cocotte-minute

"Cela m'attriste aussi que l'entreprise n'obtienne pas ce qu'elle pourrait retirer de ce contrat, mais ma principale préoccupation concerne les personnes qui font le travail."

Alors qu'est-ce qui a mal tourné ?

Fondamentalement, les organisations ont appliqué le label "Agile" pour justifier de faire claquer le fouet plus souvent contre les développeurs afin de générer plus de code plus rapidement qu'il n'est soutenable.

Cela participe à faire naître un environnement de type cocotte-minute, tout en vantant un esprit de travail collaboratif : "nous sommes tous dans le même bateau." De plus, "Agile" a pris une signification beaucoup plus large, suggérant que toute l'organisation devrait être assez souple pour en tirer un bénéfice.

Agile est devenu un mantra pour pratiquement toutes les entreprises. Ainsi, 97% des organisations de l'enquête State of Agile 2018 déclarent pratiquer les méthodes de développement de logiciels Agile.

Comme l'explique Jeffries, un tel abus ou mésusage du concept conduit à "plus d'interférence avec les développeurs, moins de temps pour faire le travail, une pression plus forte, et des demandes pour aller plus vite."

Des approches "Faux Agile" ou "Dark Agile"

Cette mise en œuvre se révèle préjudiciable pour les développeurs, et, au bout du compte, mauvaise pour l'entreprise aussi. Mal faire de l'Agile entraînera, le plus souvent, beaucoup plus de défauts et des progrès nettement plus lents que ce qui aurait pu être réalisé. Souvent, les bons développeurs quittent de telles organisations. In fine, une entreprise se montre moins efficace qu'avant l'implémentation d'Agile."

Jeffries qualifie ces approches de "Faux Agile" ou "Dark Agile". Plutôt que de favoriser la créativité et la collaboration au sein d'une organisation, de telles approches aboutissent à imposer un autre système ou processus semi-supporté dans une philosophie "marche ou crève."

Comme le dit Jeffries : "Les méthodes Agile à plus grande échelle semblent en réalité recommander l'imposition de processus, notamment la méthode dite 'SAFe', Scaled Scrum et LeSS, entre autres. Elles sont présentées à l'entreprise et on attend d'elle qu'elle les 'installe' ou les 'déploie'. En tant que développeur, vous pouvez être sûr que ce déploiement ne se fera pas sans heurts ni de manière vraiment agile. Vous ne serez probablement pas entraîné, encore moins formé, ni n'aurez l'aide dont vous avez vraiment besoin pour faire votre travail."

La promotion de l'Agile vise également à rassurer les chefs d'entreprise et les DSI sur le fait qu'ils sont "branchés" aux dernières réflexions sur la gestion d'une entreprise et la manière d'être compétitif comme une entreprise du XXIe siècle. Après tout, chaque entreprise est désormais une entreprise logicielle.

Plutôt que d'être broyés par ces tentatives de bousculer les organisations pour qu'elles deviennent "Agiles", Jeffries appelle les développeurs à continuer de viser l'excellence, mais aussi à faire revivre et promouvoir les concepts originaux et intemporels du Manifeste Agile, dont les éléments suivants :

• "Produisez des logiciels en production, testés, fonctionnels et intégrés toutes les deux semaines, chaque semaine. Développez vos compétences jusqu'à ce que vous puissiez créer une nouvelle version entièrement opérationnelle tous les jours, deux fois par jour, plusieurs fois par jour."
• "Préservez le design de ce logiciel. A mesure qu'il grandit, le design aura tendance à devenir complexe et redondant. Résistez et inversez consciemment cette tendance, remaniez en petites étapes continues, tout le temps, de sorte que votre rythme de progression soit aussi stable et cohérent que possible."
• "Utilisez l'incrément actuel du logiciel comme base pour toutes vos discussions avec votre direction et gestion produit. Parlez de ce qui est finalisé et de ce qu'ils voudraient que vous fassiez ensuite."