Kanban, un serial killer de la Definition of Done ?

Nombre d’équipes pratiquant l’agilité utilisent la Definition of Done (souvent nommée DoD) qui permet de déterminer, sur la base de critères objectifs et partagés, si la User Story est bien terminée. Ces critères servent également de «contrat» entre l’équipe et le client.

Cette DoD se traduit régulièrement par une liste de points à contrôler et est, la plupart du temps, affichée sur un des murs du bureau de l’équipe. Lors de mes accompagnements, j’ai même rencontré une équipe qui utilisait une feuille Excel remplie par chaque développeur pour toute US réalisée… ce qui me faisait penser à la traçabilité du processus Verification (VER) du CMMI-DEV, mais c’est un autre sujet.

Mais, me direz-vous, que vient faire le Kanban Lean dans cette histoire de Definition of Done ?

En Lean Management dans l’IT, nous avons l’habitude d’utiliser le tableau Kanban IT pour matérialiser un flux de réalisation tiré par la demande du client (interne ou final). Ce flux (ou processus) est donc découpé en étapes entre son point d’entrée (la demande du client) et son point de sortie (la livraison au client). L’idéal étant le flux pièce à pièce (one piece flow) rythmé par le takt time, le tableau Kanban limite de facto le nombre de pièce en cours de réalisation.

Que trouve-t-on dans la Definition of Done ? Des critères, comme indiqué en préambule de cet article. Mais si l’on y regarde de plus près, ces critères sont en fait – pour un très grand nombre – des étapes du flux de création de valeur. Exemples :

La revue de code est effectuée -> étape : Revoir le code ;
Les tests de l’US sont passés et sont OK -> étape : Tester l’US ;
Le PO a vu la démo -> étape : Présenter la Démo ;
La documentation technique est à jour -> étape : Mettre à jour la documentation technique ;
Le code est mergé -> étape : Merger le code ;
La version est déployée sur l’environnement de tests -> étape : Déployer sur l’environnement de tests.
…

Cependant, il est très courant que des US livrées n’aient pas le bon niveau de qualité ou leurs documentations nécessaires à jour, pour ne prendre que ces exemples. Cela provient d’un management visuel qui peut être amélioré (lire Le Management Visuel, pour quoi faire ?), car la DoD ainsi affichée ne sert plus. Certes, l’information est exposée et accessible par tous les membres de l’équipe, mais au bout d’un moment elle n’est plus «visible», car le cerveau s’est habitué à voir cette affiche. Amusez-vous à faire l’exercice avec des affiches corporate au sein de votre entreprise

Les tableaux des équipes que nous rencontrons sont de type À faire / En cours / Terminé (non, ce n’est pas un tableau Kanban), qui ne permettent pas à l’équipe de savoir simplement où en sont les US et ce qui se passe dans le processus, car toutes les activités de réalisation sont concentrées dans la colonne En cours. De fait, il fallait trouver une astuce pour déterminer si l’US est terminée ou pas, d’où la Definition of Done. En utilisant les principes du Kanban pour transformer ces critères en étape du flux (c’est-à-dire détailler les étapes de la colonne En cours), les équipes peuvent voir quotidiennement l’avancement des US… et bien plus !

Pour mémoire, les auteurs de La Stratégie Lean définissent ainsi le management visuel :

« La visualisation est une technique propre au Lean, qui anime l’espace de travail et permet aux collaborateurs de se confronter facilement aux problèmes car ils leur sautent aux yeux. »

Les critères de la Definition of Done de type étape sont habituellement transformées, par les équipes pratiquant l’agile, en tâches (en plus de l’US) dans le sprint – pour ne pas oublier de les réaliser – et viennent compléter (surcharger ?) la colonne En Cours. Avec le tableau Kanban IT, nul besoin de ces tâches complémentaires car la fiche Kanban de l’US traverse l’ensemble des étapes à réaliser. Donc, si pour une US il est nécessaire de mettre à jour la documentation technique (un des critères de la DoD), cette dernière sera réalisée lorsque la carte Kanban de l’US se trouvera dans la colonne ad-hoc.

Prenons l’exemple du critère Les tests de l’US sont passés et sont OK. Avec un tableau classique, la fiche d’une US KO ne change pas de colonne et reste dans En cours avec, éventuellement, une indication. Sur un tableau Kanban IT, la fiche Kanban de l’US recule pour retourner à l’étape Réalisation et un item est créé dans le bac rouge (problème de qualité) de la colonne Tester l’US, pour déclencher une résolution de problème visant à comprendre pour quelle raison cette US n’est pas bonne du premier coup.

Quant au client, les colonnes du tableau Kanban matérialisent, de la même manière que les critères de la Definition of Done, le contrat avec l’équipe puisqu’une US est terminée après avoir traversé l’ensemble des colonnes (étapes du flux) – et selon le takt time – pour se retrouver dans la colonne Terminé.

L’article Améliorer le Kanban ou ajuster la DoD ? est l’exemple même d’une équipe de développement – fonctionnant en sprint – qui, suite à un problème de validation, a décidé non pas d’ajuster les critères de Definition of Done, mais de changer son tableau Kanban IT.

D’autres critères de DoD peuvent se transformer en indicateurs de performance de l’équipe, comme Les tests unitaires couvrent au moins 80 % du code ou encore La dette technique n’augmente pas (par rapport à un objectif). Avec ce type d’indicateur présents sur le management visuel et mis à jour à la fin de chaque sprint (ou quotidiennement avec des outils de tests / analyses automatiques lancés la nuit), des actions d’amélioration peuvent être entreprises immédiatement si le taux de couverture se dégrade.

Un jour, un développeur m’a demandé où l’on devait placer des critères comme L’application doit fonctionner sur tous les navigateurs actuels (limité toutefois sur le nombre de versions de chaque navigateur). À quel moment, ces critères doivent être testés ? Au plus tôt techniquement, donc dans l’étape de Réalisation, même si les tests métiers (lors de l’étape de Validation) peuvent les réaliser également, mais c’est déjà relativement tard dans le flux. Il peut donc être intéressant d’ajouter des critères de fin d’étape de plus bas niveau sur certaines colonnes du tableau Kanban IT. Cela permettrait à chaque personne de savoir si ce qui est fait est OK ou KO ; un des principes de base du management visuel, comme le rappellent les auteurs de La Stratégie Lean :

« Pour des raisons de motivation comme d’autonomie, les collaborateurs doivent savoir au premier coup d’œil s’ils réussissent ou non. »

Les colonnes du tableau Kanban IT ne sont pas gravées dans le marbre. Il peut être nécessaire d’ajouter une colonne matérialisant une étape pour améliorer la qualité et ce qui doit être produit dans le flux de valeur. L’important est de s’interroger sur la valeur apportée par cette étape : contribue-t-elle à ajouter de la valeur (pour le client) au produit / service ou est-ce un gaspillage (qui ajoute du délai) ?

Non seulement, le tableau Kanban IT rend «actifs» (et non plus passifs -> simplement affichés) les critères de la Definition of Done, mais il permet de rendre visible beaucoup plus de choses (le flux qui bouge ou pas, la non-qualité avec le bac rouge, les attentes, les surcharges de travail…). C’est «tout bénéf» pour l’équipe, et ce n’est que le début !

⚠️Important : évitons de croire qu’avec seulement des colonnes matérialisant un flux, l’équipe pratique le Kanban. Je vous invite à lire ou relire Kanban, que la force soit avec toi ! pour en comprendre les fondamentaux nécessaires au bon usage du Kanban.

Note : article initialement rédigé par mes soins sur le blog d’Operae Partners.