À perdre haleine

De plus en plus d'articles mettent en garde sur le danger de la mode agile.
À juste titre.
Comme tout ce qui gagne en popularité, l'agilité risque de porter le chapeau des échecs sur les projets lorsqu'elle n'est pas bien comprise, menée et accompagnée.
Voici deux articles qui traitent du sujet :

Jason Gorman nous rappelle le principe du "rythme soutenable" (par une analogie avec le sport), qui requiert une discipline agile ("Don't refactor while you have a failing test. Don't change the meaning of a test while you're refactoring"...), un certain niveau de développement, et aussi de limiter l'appétit du client, qui aurait tendance à se calibrer sur la séduisante mais trop éphémère vélocité d'une équipe.

Thierry Cros pose un regard plus général en définissant ce qu'est "être véritablement agile", c'est-à-dire "implémenter vraiment les 12 principes agiles".
C'est tout le danger de Scrum restreint à sa plus simple expression de "méthode itérative pour livrer des items prioritaires de product backlog".
Il y a des pratiques quasi-obligatoires et indissociables pour supporter cela. Comment, par exemple, faire de l'itératif sans faire correctement du TDD / refactoring sans multiplier considérablement les risques de régression ?
La seule méthode complète est XP, mais mettre en oeuvre toutes ses pratiques ne me paraît pas pour autant indispensable, notamment pour ceux qui souhaitent installer l'agilité dans leur contexte.

Pour ma part, j'ajouterais qu'il ne faut pas céder au "tout agile".
L'agilité ne répond pas à tous les problèmes de la gestion de projet informatique ! Sinon, ça se saurait...
Mal appliquée que ce soit dans sa méthode ou dans sa position, elle devient problème.
Elle doit se marier avec les bonnes pratiques de gestion "classiques", qui souvent ne se situent pas au même niveau (aspects contractuels, référentiels société, gestion des programmes, des systèmes etc)
Elle ne peut pas non plus faire abstraction de l'organisation dans laquelle elle veut s'installer. Dans ce cas, on doit certainement renoncer au "purisme agile", du moment que l'on respecte les principes minimums et indissociables.