Je suis, tellement, mais alors, tellement, pas d’accord avec cela. Car dans ta définition ma team serait la plus agile du game par exemple. Et je peux te dire pour le vivre que c’est faux. On a une capacité d’adaptation au changement qui ne fonctionne pas du tout car beaucoup trop élevée. Non, agile ne veut pas dire ce que ça dit. AGILE c’est un framework de méthodologie à suivre à la lettre pour que tout se passe bien. Agile n’invalide pas toutes les autres méthodes, et SCRUM n’est pas nécessairement la meilleure façon de travailler en agile, certes. Mais tout de même il n’y a rien de naturel là dedans et les cérémonies ne sont pas des blagues.
Par contre je dirais que agile a un coût, mais c’est pour gagner en qualité au niveau du produit et en séreinité des équipe.
Comme le dit Nohar, l’agile n’est pas un framework. C’est une approche du développement par des développeurs pour des développeurs.
Tu peux réduire l’agile à deux objectifs : avoir une boucle de feedback la plus courte possible (le temps entre le moment où on commence à développer quelque chose et celui où on a des retours utilisateur) et chercher à réduire au maximum cette boucle de feedback. Sans oublier qu’on livre toujours de la qualité (autant dans le code que dans les fonctionnalités livrées).
Et mine de rien, cela tire beaucoup de choses : on a besoin de discuter avec les utilisateurs/clients pour connaître leurs besoins et savoir comment y répondre. On doit éviter les effets tunnel pour accueillir les changements au plus tôt et livrer rapidement. On a besoin de CI/CD pour délivrer vite (ce qui tire encore plus de pratiques/principes), etc.
Mais ça reste avant tout une philosophie qui demande une approche technique, personnelle, structurelle et organisationnelle.
SCRUM est construit (et autres méthodologies) là-dessus pour fournir un framework : la boucle de feedback est déterminée par des sprints de une ou deux semaines avec démo/sprint review. L’amélioration continue par la rétrospective.
L’avantage, c’est que SCRUM donne un cadre normé auquel il est facile de s’attacher et permet notamment aux équipes nouvelles de se lancer dans un développement agile (c’est une des raisons pour lesquelles on commence par SCRUM).
L’inconvénient de SCRUM, c’est qu’il donne le sentiment d’être agile sans l’être (culte du cargo) : si tu fais des sprints de deux semaines mais que tu ne livres qu’une fois tous les 6 mois, ta boucle de feedback est de 6 mois. Si tu fais des rétro sans en sortir la moindre idée d’amélioration que tu mets en place immédiatement, tu ne fais pas d’amélioration continue. Si l’équipe doit attendre le retour de vacances de l’UX (ou PO) pour discuter avec les utilisateurs, tu ne peux pas t’adapter.
Je n’entrerai pas dans les détails des estimations, sprint plannings, etc. mais il y aurait aussi des choses à dire…
Dernier point : SCRUM est orienté gestion de projet alors que l’agile est pour les équipes de développement (sans compter que SCRUM est tellement bien qu’on a besoin d’une personne dans chaque équipe pour forcer les autres à suivre le process)
Si tu veux plus d’infos sur les déboires des méthodologies comme SCRUM, tu peux lire les articles comme the tragedy of craftsmanship de Uncle Bob, agile hangover de Sandro Mancuso ou developers should abandon agile de Jeffries. En français, tu peux regarder la conférence de Arnaud Lemaire Et si on redémarrait l’agile ?