Agile ?

L’agilité ? Oui, mais avec un devis à 2 décimales près, s’il vous plaît.

Bon, l’agilité, c’est bien. Enfin… sur le papier. Tout le monde en parle, tout le monde l’adopte. Ou plutôt : tout le monde dit qu’il l’a adoptée. C’est un peu comme la salade au restaurant le midi, tout le monde la regarde, mais à la fin, c’est toujours la pizza qui gagne.

Mais entre le manifeste agile affiché sur les murs de la salle de réunion et la réalité des projets, il y a parfois un petit monde. Ou un océan. Ou un multivers. Avec des trolls en daily, des orques dans le backlog, et des elfes invisibles quand il faut tester.

Je me souviens d’un vieux dessin sur le site Comit Strip (ceux qui savent, savent), où l’on demandait à une personne de faire les courses de manière agile… mais en lui imposant de dire au centime près combien ça allait coûter. Et bien sûr, en validant la liste à l’avance, avec une estimation jour/homme du passage en caisse.

Voilà. C’est ça, l’agilité à la sauce corporate.

Estimer, ce n’est pas promettre

On a beau le répéter : une estimation n’est pas un engagement. C’est une boussole, pas un GPS avec recalcul automatique. Mais curieusement, dès que tu sors une estimation, elle se transforme instantanément en engagement gravé dans le marbre (et inscrit dans le contrat, au passage). Comme si tu promettais une éclipse solaire à date fixe.

« Tu avais dit que ce serait prêt en 3 sprints. Pourquoi ça ne l’est pas ? » — Parce que la réalité, les inconnues, le code legacy, la météo et Mercure en rétrograde. Et aussi parce que le café du matin n’était pas très bon.

L’agilité, ce n’est pas livrer vite, c’est s’adapter

Trop souvent, l’agilité est perçue comme une usine à vélocité. Comme si le but était juste de livrer toujours plus vite, toujours plus court, toujours plus avec moins. La méthode miracle pour faire rentrer 10 jours de dev en 2 sprints… sans magie, juste de la pression.

Mais à la base, l’agilité sert à naviguer dans l’incertitude, à collaborer, à tester, à ajuster. À être humains.

Et oui, parfois, ça veut dire non. Ou « je ne sais pas encore ». Ce qui est insupportable pour certains. Parce qu’ils attendent des certitudes dans un backlog magique.

L’agilité sans la confiance, c’est juste du théâtre

Faire des dailys à l’heure, coller des post-its partout, suivre les cérémonies à la lettre… ce n’est pas ça, l’agilité. Ce qui fait la différence, c’est la confiance dans l’équipe. Sans ça, on n’est pas agile. On fait juste semblant. On fait du théâtre de l’agilité, avec costumes et backlog, mais sans âme et sans les applaudissements à la fin.

Anecdotes (100% vécues ou presque)

1. Les US à 5 minutes

Sur un projet, auquel heureusement, je n’ai pas participé, mais le bureau n’était pas loin… Les US sont estimées au plus juste. Très bien. Apparaissent des US comme : « Ajouter l’utilisateur X », « Donner les droits à l’utilisateur Y », qui sont des stories estimées à… 5 minutes. Ou 10. Voire 15. Pas parce qu’elles sont simples, non. mais parce que l’on veut « pouvoir planifier au plus fin ».

Ah oui ? Mais la réalité dépend de trop de facteurs pour être aussi précis ! Et juste le temps de se connecter à l’application de suivi, de lire, de déplacer à « En cours », puis à « Done », Cela prend déjà plus de temps que le temps estimé mais « c’est l’agilité, faut être réactif ». Donc maintenant, on fait des tickets qui prennent moins de temps à faire qu’à les décrire et l’on a une personne qui fini à 3h du matin car le temps « autour » des US n’est pas compris dans la liste des US à faire.

2. Les US de 5 mots

Autre pépite : une User Story qui tient en 5 mots et qui donne plus un objectif lointain qu’une exigence qui peut tenir dans un sprint. Quelque chose comme : « Je veux un écran dans l’application qui permet de faire des rapports. » Et c’est tout. Pas de critères d’acceptation, pas de contexte, pas de description. Et quand l’on demande des précisions, la réponse est « Ben tu fais un truc standard, non ? ». Ah oui, bien sûr. Une appli web de reporting standard. Facile. Je suppose que c’est comme demander à un architecte bâtiment « je veux une maison pour vivre dedans ». Bon courage.

3. Les changements d’objectifs à chaque sprint

Sur un autre projet, le backlog était vivace. Très vivace. Trop vivace. Chaque sprint débutait avec des objectifs… qui étaient redéfinis deux jours après. « Ah finalement le besoin a changé », « Le directeur veut autre chose », « On a une nouvelle priorité ». Conséquence : des sprints jamais terminés, des stories constamment stoppées en plein vol, et des rétrospectives devenues des groupes de parole de désillusionnés. Parce qu’en agilité, oui, on peut changer d’avis. Mais pas à ce point-là. Sinon, on n’avance jamais. Et on fatigue tout le monde. Pour celui-ci, le projet est tout de même mis en production… Mais personne n’a jamais utilisé l’application. Jamais personne ne s’est connecté. Même pas le PO.

4. Les dépendances bloquantes

Et parlons des dépendances. Ah, les fameuses. On veut aller vite, mais on est bloqués par une autre équipe. Ou par une API pas encore prête. Ou un accès à une base, en attente depuis deux semaines. Et chaque jour, au daily, la même phrase : « Toujours bloqué sur ce ticket, on attend. ». Mais personne ne remet en cause le fait que l’équipe censée être « autonome » est en fait pieds et poings liés par des dépendances techniques et organisationnelles. Mais chut. Ce n’est pas très agile de se plaindre.

5. Zéro architecture, zéro vision

Un autre classique : on veut aller vite, donc on « code tout de suite ». Pas de temps pour faire une architecture. Pas de réflexion sur la scalabilité, les choix techniques ou les interdépendances. Résultat ? Une usine à gaz au bout de 3 sprints, et un refactoring complet après la mise en production. L’agilité ne signifie pas qu’on oublie la conception. Elle signifie qu’on l’adapte, qu’on la rend évolutive, mais certainement pas qu’on la supprime.

6. Pas de retour arrière possible

Dans certaines équipes, le backlog est sacré. Une story mise en « done » est figée à jamais. Impossible de la rouvrir, de la remettre en question, ou de revoir une décision précédente. Pourtant, apprendre de ses erreurs, c’est la base. Si tout est figé une fois terminé, alors où est l’adaptation ? Où est la boucle d’amélioration continue ?

7. Rétrospectives sans effet. Pas de remise en question

Les rétrospectives sont là pour ça, non ? Sauf que parfois, elles deviennent un théâtre de bonnes intentions où rien ne change vraiment. On remplit des post-its, on fait un tableau des « keep / drop / try »… et puis on oublie tout dès le sprint suivant. Pire : dans certaines équipes, critiquer l’organisation ou remettre en question un choix est mal vu. L’agilité devient alors une camisole de processus.

8. Pas de spécifications, mais pas de discussion non plus

Travailler sans spécifications détaillées, pourquoi pas, si on compense par la communication. Mais quand on enlève les specs et qu’on n’a pas de PO dispo, pas de vision produit, pas d’atelier… alors on fait quoi ? On invente. Et ça finit rarement bien.

Comment s’en sortir : remettre l’humain et le bon sens au cœur

Pour éviter ces pièges, il faut revenir à l’essentiel : l’agilité, ce n’est pas une méthode miracle, c’est un état d’esprit. Voici quelques pistes à suivre:

• Travailler la relation avec le client : le former, l’accompagner, lui expliquer que l’agilité implique une part d’incertitude… et que c’est normal.
• Protéger l’équipe : lui donner un cadre clair, un Product Owner accessible, une capacité à dire non ou à poser des limites.
• Favoriser la discussion : plutôt que des specs rigides, faire des ateliers, du partage, des maquettes, des échanges réguliers.
• Accepter de changer d’avis : sur les objectifs, sur les décisions techniques, sur les pratiques internes. C’est sain.
• Faire de vraies rétrospectives : et en tirer des actions concrètes. Ce n’est pas juste un rituel, c’est un levier de progrès.
• Conserver une vision : avec ou sans architecture formelle, il faut une direction. L’agilité ne dispense pas de réfléchir avant d’agir.

Conclusion : arrêter le théâtre, revenir au bon sens

L’agilité, ce n’est pas une checklist, ni une série de cérémonies. C’est une philosophie de travail basée sur la confiance, la transparence et l’adaptation intelligente.

Vouloir l’appliquer à la lettre sans en respecter l’esprit, c’est comme faire un marathon sur un tapis roulant : tu cours, tu transpires, mais tu n’avances pas.

Alors arrêtons de faire semblant d’être agiles. Soyons-le vraiment. Et si ce n’est pas possible, ayons au moins l’honnêteté de ne pas prétendre le contraire. Et surtout, offrons un bon café au PO. Il en aura besoin.