Je crée un topic dédié aux méthodes de développement pour avoir un endroit où poster cet article que je trouve assez intéressant.
Il décrit, en seulement quelques paragraphes mais de manière très juste (à mon avis*), les limites et problèmes des méthodes agiles telles qu’on les applique en ce moment.
L’article date de novembre 2018 mais vient de se faire reprendre sur HN et Reddit, où ça commente activement.
* à part le name-dropping au milieu que j’ai trouvé agaçant
Le top ca serait une méthode agile pour le relationnel client-dev qui enrobe une maniere de coder en cycle en V 
Parce que bon ca dépends des secteurs d’activité, mais j’ai trop souvent vu « methode agile = excuse pour dev cheap et rapide sans véritable methode/procedure »
On s’en rends compte au moment des audits/incident de sécu
Depuis un an, je bosse comme expert scientifique pour une boite d’avocat pour leur client faisant du CIR.
Les “méthodes agiles” utilisés par beaucoup de boite dans leur R&D sont aussi une justification pour ne pas faire de doc “bah on a nos stories, on a pas de de doc type cycle en V” … résultat c’est un calvaire de prouver aux impots que les mecs font de la vrai R&D sans doc XD
La méthode Agile n’est peut-être pas parfaite mais quelques fois ça n’en a que le nom: un mélange de méthode à l’arrache, de cycle en V avec une dénomination Agile qui n’a rien à voir avec la choucroute sauf à se la jouer aux comités de direction.
Parce que ça a donné de si bons résultats que ça par le passé, le cycle en V pour le dev ? 
Les mauvaises équipes n’ont pas attendu les méthodes agiles pour skipper la doc ou la sécu.
Yep, mais maintenant Agile leur donne une excuse pour skipper la doc.
Ce qui est moche c’est quand des équipes font des outils de détection d’anomalie (comme l’intrusion) en méthode agile pour alimenter leur SoC, et qu’au final ils n’ont quasi aucune doc derrière …
Amen sur toute la ligne… et je sais malheureusement de quoi je parle, c’est mon gagne-pain >_<
Quand je suis optimiste, je me dis que le problème vient du fait que la transition d’un état (plan-driven) à l’autre (value-driven) est souvent très long. Ca n’est pas comme un interrupteur « hop, on change d’état et maintenant on est agile ». Donc 99% de tout ce que l’on voit qualifié d’« Agile » dans la nature, est en fait « (transitionning to) Agile ». Ce qui vide le terme de tout sens.
Et quand je suis pessimiste, je me dis que le terme « agile » est en fait devenu une excuse pour faire tout et n’importe quoi… à commencer par ignorer les principes de l’eXtreme Programming (cf le fantastique talk « 7min26 seconds » de JB Rainsberger ci-dessous), coder comme ses pieds sous couvert de « oh c’est bon, c’est de la dette technique » (cf video TechnicalDebt vs Cruft de DocNorton ci dessous) et surtout ignorer la deuxième partie de la première phrase de l’Agile Manifesto:
We are uncovering better ways of developing software by doing it and helping others do it.
Un coach agile qui n’est pas impliqué dans le système, qui n’est pas capable de s’asseoir dans l’équipe et prendre part a la création de valeur, ne fait que « helping others do it »… et fait donc partie du problème.
7 min 26 Seconds and the fundamental theorem of Agile Software Development by JB Rainberger
The technical debt trap by DocNorton
J’avais vu passer une proposition intéressante (je ne sais plus où par contre): remplacer le terme “dette technique” par “risque technique”.
Risque à la fois sur le fonctionnement de l’application (mais ça il arrive que le client s’en foute: si ça pète c’est la faute des devs) mais surtout risque sur le planning: plus le risque technique est élevé, plus ta prévisibilité est faible.
Normalement c’est sensé être plus audible par le client (ou PO, PM… insérez votre décisionnaire préféré) qu’un concept de dette technique qu’on peut continuer à accumuler en laissant les suivants la payer.
Je n’ai pas encore eu l’occasion de tester ce changement de vocabulaire, mais je le garde sous le coude pour la prochaine fois où je croise un PO qui voit le temps consacré aux tâches techniques comme une faveur accordée aux devs.
Oui mais non 
tout dépend du pourcentage et de la fréquence.
Une mission d’un an et demi où j’étais PO, pour un outil technique BI, c’était vraiment dur de faire avancer les fonctionnalités qui sont quand même l’objectif in fine d’un projet. Un PO d’un projet voisin avait trouvé le truc, que j’essayais d’appliquer : avoir 20% de user story fonctionnelles par Sprint. Sinon cela aurait été un peu trop fréquemment 100% technique.
Après je comprends la nécessité de prendre du temps pour la dette technique, la factorisation, etc… surtout que j’ai retrouvé un boulot de développeur depuis un an et demi en R Shiny et je suis confronté à ces nécessités (même si je suis dans un environnement à l’arrache… mais qui fonctionne vu la disponibilité du responsable et la taille de l’équipe : moi).
Sinon un article sur les soucis de la mise en avant de l’Agilité qui se révèle dans certaines entreprises davantage un appeau à développeur utilisée comme instrument coercitif :
Il tient aussi une chaîne Scrum-Life : souvent très intéressante, il ne faut pas s’arrêter à son côté un peu clown.
Là au boulot sur un projet on a accumulé 3 ans de dette technique, on le paye fort là, 0 nouvelles fonctionnalités importantes depuis 2 ans.
C’est pesant commercialement et techniquement
oO ?!
À ce propos, et en lisant l’article ci-dessous, pour le cœur de la saisie de données, on s’appuie sur une solution technique 32 bits en client lourd, développée il y a 15 ans. 
qui était très bien à l’époque mais qui rame, qui agace donc les utilisateurs, et devient problématique techniquement pour se lier à l’écosystème technique actuel.
Mais ça reste intéressant ? Tu es prestataire ou salarié de client final ? Je veux dire: herbe plus verte ailleurs, tout ça ? 
J’ai connu un projet où l’équipe avait péniblement négocié 20% de tâches techniques par sprint. Sur une plateforme de plusieurs dizaines de microservices je ne te raconte pas la taille de la dette technique au bout de quelques années…
Je pense que nous sommes d’accord sur le fait que la seule valeur qui compte, c’est la valeur fonctionnelle apportée au client. Mais cette valeur ce ne sont pas seulement des features, ce sont beaucoup d’autres choses qui contribuent de façons plus indirectes à la valeur client, surtout si tu commence à regarder dans la durée.
Par exemple:
Tous ces points passent par des tâches techniques qui peuvent apparaître comme inutiles aux yeux de personnes peu au fait de la manière dont fonctionne un projet info.
La seule manière de s’en sortir, c’est que tout le monde (devs + PO) comprenne les enjeux
et rame dans le même sens (parce que des devs en roue libre qui font de la tech pour la tech, j’en ai vu aussi). Ça demande beaucoup de confiance des deux côté et c’est rarement facile.
Mouais, je n’aime pas trop ce genre d’article à base de « si ça ne marche pas c’est que vous n’avez pas compris ». Ça a longtemps été un argument pour le communisme: « nan mais tu comprends, le vrai communisme ça n’a jamais été appliqué ». Alors qu’en fait, non, le communisme ça ne marche pas.
Une méthodo qui est tellement compliquée à appliquer qu’elle foire dans 95% des cas, ce n’est peut-être pas une si bonne méthodo que ça.
Ceci étant dit, j’ai beau ne pas aimer le mini waterfall Scrum (Kanban FTW), l’auteur n’a pas complètement tort non plus. Les principes agiles sont malheureusement courramment réduits à quelques process suivis plus ou moins aveuglément histoire de pouvoir aposer un tampon « on fait de l’agile » sur une équipe.
Tu arrives en parlant de la méthode Agile à frôler le point Godwin ! trop fort 
Personnellement avant d’en faire je croyais que c’était du vent et j’ai adoré : si j’ai toujours évité d’être chef de projet de ssii en revanche j’ai beaucoup apprécié d’être PO car ça correspond mieux à mon caractère et le fait qu’il faut convaincre, ainsi que l’aspect quasi horizontal et la fréquence rapide de livraison.
Mais je connais les défauts de la méthode Agile, notamment une pression qui peut être plus forte sur les dévs, du justement à l’organisation horizontale.
Et malgré les défauts que j’ai vu, et le biaisage de la part de la direction, sans parler de certaines influences toxiques, je l’ai vu pas si mal fonctionner (en tout suffisamment pour me convaincre), contrairement à certains régimes politiques dont tu parles.
Cependant à choisir, si je préfère la méthode Agile, en revanche à mon avis les organisations hiérarchisés en V assumées sont préférables à l’Agilité dévoyée et déformée à mort.
Je n’en ai fait qu’un an et demi et j’en referais bien. Et d’ailleurs pour ma mission actuelle pour un gros projet ça serait à mon avis la seule solution possible vu l’organisation actuelle.
edit:
Et je note toutes tes remarques intéressantes
Je râle mais je ne connais pas mieux que l’agile pour produire du soft de qualité qui correspond aux besoins des utilisateurs.
C’est le Scrum en particulier que j’ai dans ma ligne de mire:
Je préfère de loin le Kanban, qui est à mon sens beaucoup plus proche de la réalité de ce qu’est l’activité d’une équipe de développement, surtout quand tu as une prod à gérer et des besoins fluctuants/incomplets.
Pour le poste de PO (que je n’ai jamais exercé mais qui me semble pouvoir être passionant dans le bon contexte), j’en profite pour poster cette excellente video qui arrive à résumer en 15 petites minutes ce qui constitue l’essence du rôle dans une équipe agile:
Ayant déjà pratiqué tu n’apprendras probablement rien, mais ça peut servir aux curieux.
J’étais sur des projets Scrum/Kanban et d’autres Kanban. Et effectivement le Kanban parait moins dogmatique et plus près adaptable à la réalité. Marrant mais absurde : un manager se plaignant de ne pouvoir intervenir à sa guise voulait passer un projet de Scrum à Kanban mais en fait ça lui passait au dessus de la tête l’Agilité.
Edit:
Schéma que j’ai dans mon blouson et proche de ce que j’ai vécu sur le rôle du PO.
https://www.les-traducteurs-agiles.org/2016/11/04/role-du-product-owner-scrum.html
Tiens un article du même site se plaignant de la mode de l’Agilité en fait dévoyée:
https://www.les-traducteurs-agiles.org/2019/04/26/les-developpeurs-devraient-abandonner-l-agile.html
edit2: Il me semble avoir déjà vu la vidéo avant de trouver le schéma plus facile à mettre dans la poche, mais tu as bien
fait de la poster: très pragmatique et complète, avec des cas pratiques.
Bon, je ne vais pas continuer à dépioter un par un les articles de ce site https://les-traducteurs-agiles.org où je découvre plein d’autres articles intéressants, ni m’auto-répondre sans fusionner mon message pour faire ressortir le lien, mais cet article est vraiment malheureusement représentatif, à mon avis, de plus de la moitié des annonces où le mot Agile est dedans. Et pas si rarement dans ce genre d’annonces ils remplacent Scrum Master par PO !
26/5/16: Responsable agile de projet/Scrum Master - C’est faux, complètement faux
Je pose ça là parce que je trouve cette phrase très juste.