On a déjà 20 colonnes dans le kanban … et si on en ajoutait une de plus ?

Published in

Just-Tech-IT

8 min readFeb 20, 2024

“Nous, on aime suivre pas à pas nos activités. C’est pour cela que l’on a une 20aine de colonnes sur notre Kanban … Mais, c’est quand même chronophage !” — Un Product Owner.

On comprend que cela soit “chronophage” … Mais, on peut aussi se poser la question de l’utilité d’avoir autant de colonnes.

Un Kanban, mais c’est quoi ?

La méthodologie Kanban a été créée par Taiichi Ōno pour Toyota en 1950 dans le but d’optimiser la capacité de production de l’entreprise. Il s’agit d’une méthode de gestion des stocks qui sert à produire sur demande (le fameux “Just in time”) pour :

Réduire les coûts de production,
Éviter les gaspillages liés à la surproduction ou à une production inadaptée,
Diminuer les délais de production.

Par raccourci, on appelle “kanban” le tableau de management visuel d’activités représentées par des étiquettes.

Pourquoi utiliser un Kanban ?

“On affiche le Kanban uniquement en Daily, comme un support, mais, dans les faits, on ne l’analyse pas vraiment.” — Un Business Analyst.

Le Kanban est — hélas — trop souvent sous-exploité par les équipes alors qu’il offre de nombreux avantages :

La collaboration : L’équipe analyse le kanban, se pose des questions, réfléchit aux risques et trouve des solutions ensemble,
La visibilité du travail en cours : Le tableau peut être consulté à tout moment par les membres de l’équipe, par exemple pendant le Daily, pour observer l’avancement du travail, vérifier que les objectifs de l’itération seront atteints et gérer les risques de retard au plus tôt,
La gestion des priorités : Les Userstories et les tâches sont hiérarchisées dans le tableau pour permettre à l’équipe de connaitre les sujets prioritaires sans avoir besoin de les demander régulièrement,
La limitation du travail en cours : Pour chaque colonne d’un Kanban, l’équipe déterminera les limites minimales et maximales du nombre de Userstories ou de tâches en fonction de sa capacité. Cela permettra de prévenir de futurs les goulots d’étranglement et le gaspillage,
Le flux tiré : Pour une bonne gestion du stock et éviter le gaspillage en permettant à l’équipe de ne se concentrer que sur les tâches à forte valeur ajoutée,
Les indicateurs d’équipe : Le passage d’un Userstory d’une colonne à une autre vous permettra de le retranscrire sous forme d’indicateurs qui vous permettront de suivre votre projet, de les analyser pour avoir des données factuelles pour votre amélioration continue (exemples d’indicateurs : Lead & Cycle Time, Vélocité, Diagramme de flux cumulés …).

Un Kanban simple pour être efficace

Un développeur, en daily : “Alors je travaille sur la Userstory … Ben, je n’arrive pas à la retrouver dans le Kanban.”
“Je n’ai pas le temps de déplacer mes cartes car je privilégie le Delivery !” — Un testeur.

Vous voulez :

Garder une vision claire de ce qui est développé ?
Savoir régulièrement si les objectifs de l’itération seront bien atteints ?
Garder l’équipe motivée car elle sait où elle va ?
Donner l’envie d’être utilisé et que cela devienne un pilier pour l’équipe ?
Gérer vos risques au plut tôt ?

Alors, limitez au maximum le nombre de colonnes dans votre Kanban ! Un Kanban est très visuel. Donc, pour que cela fonctionne bien, il doit être le plus petit et le plus frugal possible.

Voici une version minimaliste :

Et une version du Kanban frugal :

Des règles d’équipe indispensables

“Le Product Owner nous a imposé plein de colonnes pour suivre toutes les étapes du delivery. On a l’impression que c’est pour nous fliquer !” — Un développeur.

Pour que l’équipe adhère, s’approprie et trouve son intérêt dans l’utilisation d’un Kanban, il est indispensable qu’il soit créé en mode collaboratif ! Cela permettra de répondre aux questions :

Pourquoi utiliser un Kanban pour suivre nos tâches ?
Pourquoi créer/supprimer cette colonne ?
A quel moment peut-on déplacer une tâche d’une colonne à une autre ?
Quels indicateurs suivre à partir des données du Kanban ? Et dans quel but ?

En plus, ce sera aussi une aide très précieuse pour embarquer rapidement vos nouveaux arrivants !

Reprenons notre exemple de Kanban frugal. L’équipe a défini les colonnes suivantes :

Backlog : Pour lister les sujets qui vont arriver par ordre de priorité,
Conception : Pour cadrer, analyser la fonctionnalité et écrire les Userstories,
Développement : Pour la phase de développement,
Tests : Pour la phase de tests de la fonctionnalité développée (cela peut comprendre la phase de pair-tests, comme la phase de Recette),
Terminé : La fonctionnalité a été mise en Production.

Elle a aussi décidé d’ajouter 3 règles de passage de colonnes pour ne plus se poser de question :

Un exemple de règles de passage de colonne

Le flux tiré pour une bonne utilisation du Kanban

“La nature a horreur du vide” — Aristote.

L’équipe tirera uniquement les tâches qu’elle sera capable de traiter. Dans notre exemple, l’équipe de test a terminé une tâche. Elle est donc capable d’en prendre une nouvelle.

C’est ce qu’elle fera, en prenant une carte disponible dans la colonne “Développement terminé”. Ce qui évitera les goulots d’étranglement et de développer à perte.

Pour en savoir plus : Flux poussé VS Flux tiré. On entend souvent parler de flux tiré… | by Silvere Duval | Just-Tech-IT | Medium

La limite sur en-cours (ou WIP) pour affûter votre Kanban

Exemple de limite sur en-cours pendant les phases de développement et de test

Il s’agit du nombre limite inférieur et supérieur de tâches que chaque colonne peut contenir et donc du travail en-cours que l’équipe peut supporter. Son intérêt est :

De maitriser la fluidité du débit de votre kanban,
D’informer d’une sous-charge ou une surcharge de travail de l’équipe,
De prévenir des goulots d’étranglement et remonter des risques,
D’éviter de lancer des sujets qui ne seront pas terminés, faute de disponibilité de l’équipe,
D’obliger l’équipe à se concentrer sur un nombre de tâches restreint afin de ne pas s’éparpiller.

Ces limites seront ajustées régulièrement, en fonction de la vie de l’équipe (nouveaux arrivants, congés, réduction d’effectif …).

Pour en savoir plus : Et si vous contrôliez votre WIP (Work In Progress) ? | by Silvere Duval | Just-Tech-IT | Medium

Le Kanban n’est pas un espace documentaire

Certaines équipes sont tellement centrées sur leur Delivery qu’elles en oublient que le Kanban n’est pas un espace documentaire. Or, sachez que les Userstories sont obsolètes dès leur mise en Production. Ces cartes ne servent qu‘à véhiculer ce qui doit être développé. Aussi, si vous souhaitez faire référence à des règles, évitez de faire un lien vers d’anciennes Userstories de votre Kanban, car elles sont peut-être obsolètes ! Qui sait, des Userstories plus récentes les ont mis à jour !

Un conseil : centralisez vos règles dans l’espace documentaire officiel de votre entreprise (Confluence, Sharepoint …) pour que toute l’équipe puisse y accéder à tout moment.

… Et il se nettoie régulièrement !

“On n’a pas osé nettoyer le Kanban, car les personnes qui ont créé ces cartes ne sont plus dans l’équipe. On ne sait pas si c’est important !” — Une équipe.

Le Kanban est un outil visuel. Il doit rester simple à utiliser. Aussi, évitez de garder ces fameuses cartes “au-cas-où” … au cas où votre Métier redemanderait la même chose dans quelques années. Elles polluent votre Kanban et vous font perdre de vue les sujets prioritaires !

De toutes façons, fort de votre expérience, vous savez parfaitement que votre Métier ne redemandera jamais exactement le même besoin … Alors, pourquoi conserver ce que l’on appelle en Green IT de la “donnée froide” ?

Pour en savoir plus : Comment nettoyer votre Kanban à la mode japonaise | by Silvere Duval | Mar, 2023 | Medium

L’amélioration continue du Kanban

Au-delà du mouvement des différentes cartes dans le Kanban, ce dernier vit aussi ! L’équipe pourra l’adapter en fonction de ses différents besoins.

Sa consultation peut être adaptée en fonction des objectifs du daily ou de points Métier,
Le nombre de colonnes pourra évoluer en fonction de la finesse du suivi que l’équipe souhaite avoir,
Les règles d’équipe pourront être ajustées en fonction des retours d’expérience de l’équipe suite aux différentes itérations,
Les limites sur en-cours seront ajustées régulièrement, en fonction de la vie de l’équipe (nouveaux arrivants, congés, réduction d’effectif …).

En résumé

“Le processus et le travail émergents doivent être visibles pour ceux qui effectuent le travail ainsi que pour ceux qui reçoivent le travail.” — Extrait du Guide Scrum 2020.

Non, le Kanban n’est pas que l’outil du Product Owner et du Scrum Master (quand on est en Scrumban, bien sûr !). C’est bien l’outil de toute l’équipe pour lui permettre de gérer au mieux son Delivery et d’être transparent vis à vis de son Métier. Si vous souhaitez que l’équipe se l’approprie et s’auto-organise, il faut le réfléchir comme un produit et penser à ses utilisateurs finaux (les membres de l’équipe).