Bien souvent les équipes de réalisation sont conscientes de cette dette mais ont un réel problème pour trouver du temps pour s’en occuper. Les Technical Story spécifiques sont bien souvent repoussées dans le bas du Product Backlog par le Product Owner et l’ajout de quelques items de qualité de code dans le TERMINE (DONE) est une bonne pratique mais bien souvent insuffisante pour s’attaquer réellement à cette dette.

Alors comment faire ?
Un de mes clients a trouvé une solution sans la chercher et tout cela grâce au Kanban.

L’objectif initial de ma mission était d’améliorer le fonctionnement de l’équipe de réalisation et ses interactions avec les équipes produit. Plutôt que de mettre en place Scrum et ses cérémonies que je ne trouvais pas vraiment adapté au contexte de ce client et à son fonctionnement, j’ai préféré conseiller l’approche lean et la mise en place d’un kanban comme outil de management visuel du cycle de vie des fonctionnalités.

Depuis quelques semaines ce Kanban est en place avec une colonne par étape et les limitations de WIP (Work In Progress) bien visibles. Cet outil a fait clairement apparaître un goulot d’étranglement ( »Bottleneck ») au niveau de la validation fonctionnelles des exigences (~UAT) qui est en cours de traitement, et donc les tâches en amonts ont une tendance à s’entasser devant ce goulot. L’effet induit pour l’équipe technique est qu’il n’y a plus de place vide sur le Kanban (WIP) pour démarrer les réalisations et donc, d’une certaine façon, qu’elle n’a rien à faire !

Cette opportunité a immédiatemment été utilisé par l’équipe pour s’attaquer à la dette technique (une forme de 5S), ce qui leur permet de  passer du temps sur cette activité tout en sachant que cela ne pénalise pas la productivité totale puisque, par définition, la vitesse du flux de sortie est subordonnée par le goulot, donc tant que le goulot est alimenté en permanence le système est à son maximum de vitesse.

Et vous, comment trouvez vous du temps pour réduire votre dette technique ?