Une liste de contrôle concrète pour maîtriser la dette technique en Scrum
La dette technique, c'est l'écart entre le code que vous avez livré et celui que vous auriez écrit avec plus de temps. Ce n'est pas toujours une erreur : parfois, une équipe Scrum accepte sciemment une dette pour respecter une date de livraison. Le danger, c'est la dette que personne ne suit. Après dix-huit mois de travail à distance et hybride, beaucoup d'équipes rencontrées en 2021 traînaient des raccourcis pris dans la précipitation des premiers confinements, et les intérêts commençaient à se faire sentir sous forme de livraisons plus lentes et de plus de défauts.
Le Guide Scrum reste volontairement discret sur les pratiques d'ingénierie, ce qui laisse aux équipes le soin d'inventer leur propre façon de gérer la dette. Cette liberté est saine, mais elle signifie souvent que la dette n'a ni foyer ni propriétaire. Cette liste de contrôle vise à lui donner les deux, en s'appuyant sur les événements et artefacts Scrum que vous avez déjà.
Rendre la dette visible
On ne peut pas gérer ce qu'on ne voit pas. La première tâche consiste à faire remonter la dette là où toute l'équipe et le Product Owner la croiseront dans le travail courant.
Inscrivez les éléments de dette dans le carnet de produit, et non sur une liste d'ingénierie privée : tout ce qui est hors du carnet rivalise pour un temps qui ne lui a jamais été accordé.
Décrivez l'impact en termes d'affaires : quelle fonctionnalité devient risquée, quel changement devient lent, ce que le client finit par ressentir.
Étiquetez la dette pour pouvoir la filtrer et en rendre compte, afin que les tendances soient évidentes sur quelques Sprints.
Ajoutez à la Définition de « Terminé » un contrôle qui signale toute nouvelle dette dès sa création, plutôt que de la découvrir des mois plus tard.
Décider et budgéter, pas seulement réagir
Une fois la dette inscrite au carnet, le Product Owner l'ordonne par rapport à tout le reste. Le rôle de l'équipe est de fournir une information honnête pour que cet ordonnancement soit réel et non une supposition.
Distinguez l'urgent de ce qui peut attendre. Une dette qui bloque une fonctionnalité à venir ou crée un risque de sécurité ou de conformité n'a rien à voir avec un nettoyage cosmétique. Dites ce qui est quoi.
Réservez une part stable de chaque Sprint. Une allocation prévisible — disons dix à vingt pour cent de la capacité — vaut mieux que des Sprints de nettoyage héroïques jamais planifiés.
Rattachez la dette à la fonctionnalité qui la touche. Quand vous modifiez déjà un module, corriger sa dette coûte moins cher qu'une visite séparée plus tard. Regroupez le travail.
Refusez les compromis silencieux. Si une échéance impose un raccourci, rédigez l'élément de dette qui en découle avant de clôturer le Sprint, pour que la décision soit consignée et non oubliée.
Inspecter et s'adapter à chaque Sprint
La dette est un sujet permanent de la Rétrospective de Sprint. Demandez-vous si le carnet de dette grossit ou diminue, si votre Définition de « Terminé » attrape bien les nouvelles dettes, et si la capacité réservée sert réellement au nettoyage ou se fait discrètement emprunter pour des fonctionnalités. Une équipe à distance a particulièrement besoin de ce point de contrôle, car les conversations informelles de couloir qui signalaient autrefois un code brouillon n'ont plus lieu d'elles-mêmes.
Rien de tout cela n'exige un nouvel outil ni un nouveau cadre. Il faut traiter la dette comme un vrai travail, visible au carnet, porté par l'équipe et revu comme le reste. Faites-le avec constance et les intérêts cessent de s'accumuler.
Si vos équipes de livraison traînent une dette invisible et manquent leurs dates à cause d'elle, le conseil en livraison de programmes et de projets de XNM peut vous aider à rendre la dette visible et à bâtir un plan réaliste pour la rembourser.