Officiellement, Scrum promet une meilleure qualité, des incréments « potentiellement déployables » et une amélioration continue.
En réalité, la dette technique s'accumule souvent sprint après sprint, finissant par devenir un sujet tabou.
Dans de nombreuses équipes, le sprint ressemble à une course :
• engagement envers un volume spécifique d'histoires d'utilisateurs,
• pression implicite concernant la vitesse,
• Les dates de révision se transforment en mini-échéances dictées par les besoins de l'entreprise.
Résultat : la fonctionnalité est validée, mais le code est fragile, insuffisamment testé et difficile à maintenir.
Dans de nombreuses équipes Scrum, la « définition de terminé » (DoD) se limite à :
• « il compile »,
• « Cela fonctionne sur ma machine. »
• « Il est fonctionnellement validé. »
Les nouvelles fonctionnalités sont déployées en production, tandis que les tâches invisibles mais essentielles sont reportées : refactorisation, tests automatisés, documentation minimale et mises à niveau architecturales.
L'équipe est au courant de la dette… mais elle n'existe pas officiellement :
• aucun élément dédié dans le backlog produit,
• aucune priorisation explicite,
• aucun compromis clair au niveau de l'entreprise.
Elle devient une « dette fantôme », traitée furtivement chaque fois qu'un promoteur « a un peu de temps » — autrement dit, jamais vraiment traitée.
En pratique, de nombreux Product Owners :
• manque d’autorité pour prioriser la dette technique,
• subir la pression des parties prenantes,
• manque de moyens pour mesurer l'impact technique à moyen terme. Résultat : la feuille de route se remplit de nouvelles fonctionnalités… tandis que la capacité d'évolution du produit se détériore silencieusement.
En définitive, la question à se poser est la suivante : « Acceptons-nous consciemment la dette que nous créons aujourd’hui… ou préférons-nous faire l’autruche et subir les conséquences de cette dette technique demain ? »
Scrum n'est ni le coupable ni une solution miracle.
Voici quelques moyens concrets de reprendre le contrôle
Sans prétendre offrir une solution miracle, certaines pratiques font une réelle différence sur le terrain :
• rendre la dette visible dans l'arriéré,
• renforcer la définition de « terminé »,
• allouer explicitement la capacité des sprints à la qualité,
• utiliser la rétrospective pour suivre les indicateurs techniques, et pas seulement les indicateurs interpersonnels.
La dette technique ne disparaît pas comme par magie.
Cependant, elle devient gérable une fois qu'elle est reconnue et assumée collectivement.