Un ami développeur Java m’a raconté sa mission actuelle. Les tickets ne sont pas estimés en complexité, ni en valeur métier. Non : ils sont découpés en heures. Une journée de 8h doit être parfaite sur le papier : • Huit tickets de 1h, • Deux tickets de 4h, • Ou un ticket de 5h + un de 3h. Mais si vous faites un ticket de 5h puis entamez un ticket de 4h ? - Vous avez “débordé” d’1h. - Cette heure est reportée sur le lendemain. - Il reste donc 7h à “remplir” avec d’autres tickets… et la machine repart. Chaque jour devient une équation artificielle à résoudre. Et gare à vous si vous dépassez : • Justifications interminables, • Timetracking Jira à remplir jusqu’à la nausée, • Rapports pour expliquer pourquoi une tâche a pris 30 minutes ou 1h de plus que prévu. Le pire ? Se retrouver gêné au daily de devoir annoncer qu’on est encore sur un ticket censé être clos la veille. Sous le regard du tech lead qui demande d’ajouter des commentaires supplémentaires dans Jira pour expliquer pourquoi le temps a explosé. Résultat ? Une pression énorme, surtout sur les nouveaux qui n’ont pas le temps de comprendre la base de code. Un climat de suspicion qui ronge la motivation. Et, au bout du compte, un épuisement mental qui pousse les meilleurs à abandonner… à l’image de mon ami, qui vient tout juste de poser sa démission. Appelons les choses par leur nom : ce n’est pas de l’agilité, c’est du micro-management toxique. Et aucun produit ne s’améliore avec des développeurs épuisés à force de “jouer à Tetris avec des heures”. ✅ La vraie valeur d’un développeur se mesure dans sa capacité à résoudre des problèmes, pas dans sa soumission au chronomètre. ✅ Le vrai cadre agile, lui, crée de la confiance, favorise l’apprentissage et la valeur livrée au produit. Qu’en pensez-vous ? Avez-vous déjà vécu ce type de management “à la minute près” ? #Développement #Agilité #Management #Java #Productivité #TravailEnÉquipe