Lors de la rétrospective d’une équipe pratiquant l’agilité avec un tableau Kanban au sens Lean (lire l’article Kanban, que la force soit avec toi !), ses membres se penchèrent sur les pièces réalisées (livrées) au regard des pièces à produire (les fiches Kanban présentes dans le backlog) dans le sprint. Première étape, regarder dans les bacs rouges les défauts de qualité et faire les Pareto si besoin. Cet exercice fait, il s’avéra qu’à cause de 2 tests déclarés KO, 2 fonctionnalités n’avaient pas pu être livrées ; ce que le management visuel avait révélé puisque celles-ci étaient dans le bac rouge.

L’équipe, désireuse de comprendre, se lança dans un PDCA. Pour 2 malheureuses fonctionnalités, me direz-vous ? Eh bien oui, pour 2 malheureuses fonctionnalités. C’est un des principes du Lean Management – qui s’est probablement perdu quelque part dans les techniques agiles – que de s’arrêter au moindre problème. Dans le monde idéal Lean, l’équipe aurait dû s’arrêter lors de la survenance dudit problème pour en résoudre la cause ; ce que Toyota pratique depuis des décennies. Poursuivons…

La recherche des causes

En pratiquant la technique des 5 Pourquoi ? dans le cadre de ce PDCA, elle se rendit compte que les 2 fonctionnalités à tester avaient bien été modifiées (contrôle de l’hypothèse en regardant dans le code), mais non poussées sur l’environnement de tests (contrôle de l’hypothèse en faisant un check sur l’environnement de tests). La personne chargée des tests n’ayant pas obtenu les résultats attendus conclut, très logiquement, que ces 2 fonctionnalités n’étaient pas conformes.

Les lecteurs ayant une appétence pour l’agilité se diront que l’équipe n’avait pas une vision claire et commune de la DoD (Definition of Done) de l’étape de développement… et c’est vrai, car en poursuivant le questionnement, il devint évident que tous les membres de l’équipe ne partageaient pas la même définition de la DoD et notamment le fait de rendre disponible la fonctionnalité ajoutée ou modifiée dans l’environnement de tests. Question classique : et pourquoi ? D’aucuns diront qu’elle (la DoD) n’est pas correctement écrite, d’autres qu’elle n’est pas affichée et visible par l’ensemble de l’équipe…

Les solutions

L’équipe mit en avant 2 propositions d’amélioration opposables, la première visant à mettre à jour la DoD et la seconde proposant d’améliorer le tableau Kanban pour rendre visible les cartes (fonctionnalités) disponibles sur l’environnement de tests. Un long débat a été lancé par plusieurs protagonistes.

Les 2 sont bonnes, mais l’une des deux va apporter plus de valeur à l’équipe. Laquelle va-t-elle choisir…

Ajuster la DoD ou améliorer le tableau Kanban ?

Si vous suivez mes articles sur le Management Visuel (Le Management Visuel, ce révélateur pour l’auto-organisation et Le Management Visuel, pour quoi faire ?) et le Kanban, vous aurez compris que je suis favorable au fait de rendre visible (je dirai même plus : rendre physique l’informe). Donc, d’améliorer le tableau Kanban.

Pourquoi ? Simplement parce que cette action de pousser les fonctionnalités sur l’environnement de tests est une étape du processus de création de valeur. Et, en tant qu’étape, elle doit être visible sur le Kanban de l’équipe. L’écrire dans la DoD ne changerait pas grand chose, in fine. La DoD doit, à mon sens, contenir des états et pas des étapes du processus. Si de la documentation doit être réalisée après des développements, elle doit apparaître sur le tableau Kanban et pas dans la DoD.

L’équipe a décidé – sans influence de ma part, ce n’est pas le rôle du coach Lean – de tester (principe du Lean) la proposition pour ajouter une colonne «Rendre disponible sur environnement de tests» avec ses 2 sous-colonnes («En cours» / «Fait») à son tableau Kanban.

Tableau Kanban mis à jour

Une meilleure compréhension de son flux

En ajoutant cette colonne, l’équipe a maintenant la capacité de voir si les fonctionnalités sont réellement disponibles sur l’environnement de tests ; les testeurs n’ont plus à se demander si la fiche Kanban dans la sous-colonne «Fait» de l’étape développement s’est arrêtée, ou non, avant le dépôt de la fonctionnalité sur l’environnement de tests. Du moment où une fiche Kanban est dans la sous-colonne «Fait» de «Rendre disponible sur environnement de tests», la personne responsable des tests peut prendre en charge (principe de tirer le flux) cette fiche Kanban.

Une meilleure capacité à détecter les problèmes

Certains détracteurs disent que ça fait modifier une nouvelle fois le tableau Kanban, ce à quoi je réponds qu’un management visuel – tableau Kanban ou non – se doit d’être modifié pour s’adapter au contexte de l’équipe. Il n’est pas gravé dans le marbre !

Oui, c’est une colonne de plus, mais c’est une possibilité supplémentaire pour l’équipe de comprendre ce qui se passe dans son processus. Cela lui permettra de voir s’il y a de l’engorgement dans la sous-colonne «En cours» de «Rendre disponible sur environnement de tests» et de se questionner sur les raisons. Mais également de s’interroger sur la capacité de l’équipe à délivrer en continue des fonctionnalités à tester et ainsi limiter la variabilité, la sous-charge et la surcharge.

Avant de modifier vos DoD, demandez-vous si ce que vous souhaitez y ajouter correspond à un état où à une étape.

Pour aller plus loin : Kanban IT, un serial killer de la Definition of Done ?

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