La mort lente et douloureuse d’Agile et de Jira
(ehandbook.com)« Agile n’est plus vraiment Agile ; il est donc temps qu’Agile disparaisse avec Jira. »
- Les cycles de développement logiciel s’allongent, les équipes techniques grossissent, la gestion du développement exige toujours plus d’applications, il y a de moins en moins de personnes qui codent réellement et, sur des périodes toujours plus courtes, les progrès entre les points de contrôle continus diminuent toujours davantage.
- Où est-ce qu’Agile a commencé à dérailler ?
- Agile est une méthodologie développée au début des années 2000 comme alternative aux processus de développement logiciel lourds et centrés sur la documentation.
- Mais aujourd’hui, Agile se transforme en une méthode de gestion de projet complexe, semblable à celles qu’il était censé remplacer.
La bloat technologique (Tech Bloat) est le problème principal
- La principale raison pour laquelle beaucoup abandonnent Agile, ou envisagent de le faire, est la bloat technologique.
- La bloat technologique est l’ennemie de toutes les entreprises tech et représente aussi un risque pour les entreprises non technologiques qui ont des équipes de développement internes ou externalisées.
- La bloat technologique est différente de la dette technique, mais elle en génère.
- Les symptômes de la bloat technologique sont les suivants :
- parler régulièrement aux clients sans pour autant devenir expert de leur comportement ;
- évaluer et réévaluer en permanence les échéances et les dates de livraison ;
- une réticence extrême à lancer le processus de développement tant que chaque détail n’a pas été documenté ;
- une motivation à commencer par les tâches les plus faciles plutôt que par les plus risquées.
Les conséquences chaotiques de la bloat technologique
- Augmentation de la documentation
- La documentation qui suit non seulement ce qui a été développé et pourquoi, mais aussi « comment » cela a été développé, s’infiltre dans le processus.
- Ce « comment » devient le cœur des mises à jour de statut, ce qui conduit à réévaluer sans cesse la manière dont l’équipe travaille.
- Les équipes passent plus de temps à discuter des raisons pour lesquelles le travail n’est pas terminé qu’à le faire réellement.
- Multiplication des échéances
- Davantage de délais sont fixés à des points de contrôle plus fréquents, ce qui engendre de la microgestion à chaque étape d’un processus pourtant fondamentalement créatif.
- Cela va à l’encontre de la production d’un logiciel de qualité, car tout doit être livré à une date donnée, quelle que soit la qualité d’exécution.
- Le doute permanent dans le processus de réévaluation
- Pendant les périodes de réévaluation, ce doute constant empêche de déclarer des bonnes pratiques, d’éliminer le gaspillage et de reconnaître les économies d’échelle.
- La microgestion du processus de production
- Lorsqu’environ 30 % d’une fonctionnalité complète est terminée, elle cesse souvent d’être prioritaire.
- L’organisation entre alors dans une spirale mortelle consistant à produire ce qui figure sur la roadmap, sans se demander si cette roadmap définit encore la construction d’un produit réussi.
- Résultat final
- Le produit souffre sous le poids de demandes clients variées et contradictoires.
- Les fonctionnalités arrivent souvent tard sur le marché et sont livrées dans l’ordre et selon la méthode les plus adaptés à l’équipe technique, et non au marché.
- Au final, les équipes commerciales et marketing se rebiffent, car elles ne savent plus ce qu’elles vendent, et les clients ne savent plus ce qu’ils achètent.
- L’organisation se lance alors dans un grand ménage.
Le monde a besoin de logiciels légers qui excellent sur l’essentiel, pas de davantage de fonctionnalités
- Ce n’est pas une idée nouvelle, mais c’est une idée dont toutes les méthodologies finissent par s’éloigner.
- Les gens finissent par se demander si la méthode Toyota est encore suffisamment « Toyota » pour Toyota, et cela devient en soi un générateur de travail supplémentaire.
- Agile est désormais devenu un PMP avec un nom plus mignon, des réunions plus courtes et davantage de règles.
- Le problème n’est pas l’idée d’Agile, mais son exécution et l’absence de leadership capable de la garder sous contrôle.
- C’est un problème de management intermédiaire, focalisé sur les délais plutôt que sur l’utilité, sur les coupes plutôt que sur la croissance, et sur les économies plutôt que sur le progrès.
L’avis de GN⁺
- Agile, à l’inverse de son intention initiale, se bureaucratise et se formalise, au point de ralentir le développement logiciel.
- La bloat technologique est un facteur de risque à surveiller non seulement dans Agile, mais dans toute organisation technique.
- La documentation, la fixation d’échéances et la microgestion peuvent au contraire dégrader la qualité et la vitesse.
- L’essence d’Agile repose sur l’orientation client, la collaboration et la flexibilité ; il faut donc revenir à ses principes plutôt que de s’enfermer dans les formes.
- En développement logiciel, l’important n’est pas d’ajouter toujours plus de fonctionnalités, mais de bien implémenter les fonctions essentielles.
- La culture d’organisation et le leadership déterminent le succès ou l’échec d’Agile ; les responsables techniques doivent donc y prêter une attention particulière.
- Il semble temps d’explorer de nouvelles méthodologies au-delà d’Agile.
17 commentaires
Comme l’article original est payant, je n’ai pas pu le lire jusqu’au bout, mais je pense qu’il serait bon d’affiner un peu la formulation de la traduction.
« Comme Agile n’est plus agile, il est désormais temps qu’Agile disparaisse avec Jira. »
=> « Puisqu’Agile a cessé d’être agile, il est désormais temps qu’Agile disparaisse avec Jira. »
Il existe une distinction conceptuelle entre
Agileavec une majuscule etagileavec une minuscule,et
being agileetdoing agile, bien que liés, sont pensés séparément.being agilebydoing agile.La raison de l’adoption de l’Agile est essentielle. Est-ce qu’on l’adopte pour mieux développer ? Non : c’est plutôt « je ne supporte pas de vous voir glander ; je vais vérifier à quel point vous travaillez dur ». C’est avec cet état d’esprit qu’on l’adopte. Alors forcément, ça devient l’enfer.
À ce stade, on dirait qu’il va falloir une checklist de conformité agile.
Au-delà du débat entre Agile et waterfall, si l’environnement — les personnes, la culture, etc. — reste inchangé, imposer n’importe quelle méthodologie de développement, aussi innovante soit-elle, ne mènera qu’à une version à la coréenne du K-OOO.
Du point de vue du développement, s’il n’y a (presque) aucun changement de spécifications, il est vrai que le waterfall est une méthode vraiment confortable. À condition qu’il n’y ait justement aucun changement de spécifications…
L’agilité version K n’est même pas réévaluée..!
Client : ce serait mieux si le bouton était ici sur cet écran
Développeur : (ça veut dire que je vais encore devoir passer la nuit dessus alors qu’il y a aussi de nouvelles tâches)
Client : il faudrait qu’il y ait un bouton sur un autre écran
Développeur : (que quelqu’un utilise le clonage sur moi) oui haha..
Client : ce n’est toujours pas prêt ? Ça aurait déjà dû être terminé selon le planning, non ?
Développeur : (au secours) oui..;;
Il semble qu’il y ait peu de cas où l’agile est utilisé de manière vraiment agile sur le long terme,
et que la plupart des organisations finissent par converger vers un travail en waterfall avec des délais courts.
Le problème, ce n’est pas l’agile. Ce sont les gens qui le pratiquent. Quelle que soit la méthodologie qu’on apporte, au final tout dépend de la manière dont les personnes l’appliquent. Pour moi, l’agile n’est pas une méthodologie, mais plutôt un état d’esprit consistant à faire progresser le produit à intervalles réguliers. Si on passe à côté de cela et qu’on se contente de faire du planning et des rétrospectives de manière aveugle, j’ai l’impression que c’est une perte de temps.
Je pensais que ce n’était le cas que du k-agile, mais apparemment c’était un phénomène mondial.
On a quand même l'impression qu'ils tapent sans cesse à côté de la plaque... Le critère devrait plutôt être de savoir si ça correspond ou non au Manifeste Agile...
Même Uncle Bob, qui a participé au Manifeste Agile, a compris ce problème très tôt et a publié en 2019 le livre Clean Agile pour corriger les dérives de l’agile, mais ce genre de problème persiste encore. Personnellement, je pense que c’est parce que l’agile n’a pas de lignes directrices standardisées et s’appuie sur l’expression vague de « culture ». J’aimerais qu’on propose des lignes directrices standard plus concrètes.
L’auteur semble penser qu’il faudrait probablement abandonner n’importe quelle méthodologie dès qu’elle devient bureaucratique.
Je suis d’accord. J’ai l’impression qu’il y a de plus en plus de cas où l’on pratique un Agile mal compris, puis où l’on affirme qu’Agile est erroné.
D’un autre côté, je me dis aussi que, même si cela fait déjà pas mal de temps que c’est apparu, il semble inévitable qu’il soit difficile d’accumuler de bonnes pratiques.
Après tous ces détours, on revient au point de départ ?
Commentaires sur Hacker News
Les problèmes d’Agile
Les principes du manifeste Agile
Le cœur d’Agile
La flexibilité d’Agile
Avis sur JIRA
Les origines d’Agile
La situation actuelle d’Agile
Les problèmes de JIRA
L’application d’Agile