Quelles colonnes à la une ?

Ce n'est pas en ajoutant des colonnes à un tableau que le système sera plus fluide

Quelles colonnes à la une ?

Les photos de tableaux Kanban montrent souvent des murs recouverts de post-it placés dans de nombreuses colonnes. Ceux qui découvrent cette technique peuvent être amenés à penser que c’est bien d’avoir plein de colonnes. Cela dépend d’où on vient, car l’idée avec Kanban est de représenter le processus actuel, pour l’améliorer.

Sur la photo, Olivier Azeau présentant 2 ans dans le flux à Montpellier.

Quand on vient de Scrum, on a habituellement comme éléments de travail des stories et des tâches. Les stories ont un cycle de vie qui commence dans le backlog avant le sprint et les tâches vivent sur 3 états : à faire, en cours (ou à finir) et fini, avec les colonnes qu’on voit dans les tableaux Scrum.

J’ai déjà expliqué pourquoi je n’étais pas convaincu par la 4ème colonne que certains ajoutent dans les tableaux.

Et si on arrête Scrum, on peut bien mettre les colonnes qu’on veut ?

A Agile tour Montpellier, le 29 novembre, j’ai assisté à un beau retour d’expérience “Deux ans dans le flux”[1].

C’est Olivier Azeau qui a présenté cette session. Au moment du passage au flux, en avril 2011, il avait annoncé que son équipe arrêtait Scrum.

C’est l’histoire d’une équipe qui faisait du Scrum et qui a arrêté : plus de sprints ! Le rythme quotidien est conservé pour le standup meeting, mais la planification, la revue et la rétrospective se font maintenant sur demande.

A noter que l’équipe a aussi arrêté les estimations de type planning poker[2]. Mais ce dont je veux parler, c’est du tableau.

Toujours des stories et des tâches. Le tableau à 2 niveaux n’a pas changé avec l’arrêt de Scrum. Pas besoin.

Cette belle transition de Scrum vers du flux (Olivier ne dit pas Kanban) s’est faite sans ajouter de colonnes. Pourtant l’équipe fait des tests, elle est même très en pointe dans l’automatisation, avec des spécifications exécutables.

Aux équipes Scrum qui réclament des colonnes supplémentaires[3] parce qu’elles font du test, de la validation, du déploiement… je conseille d’y réfléchir à 2 fois : c’est une facilité qui cache un problème (l’équipe n’est pas multidisciplinaire ) et qui ne va pas améliorer la performance du système si on ne l’accompagne pas de solides pratiques Kanban bien maîtrisées. Cela s’adresse d’abord aux équipes Scrum mais peut aussi servir à celles qui cherchent à représenter des processus non séquentiels.

Notes

[1] J’ai assisté aussi à d’autres sessions très intéressantes, Fabrice en parle dans sa rétrospective #atmtp .

[2] Elle a arrêté les estimations, mais pas les prévisions, qui sont faites à partir de mesures du temps de réalisation en utilisant la méthode de simulation de Monte carlo.

[3] Je sais qu’il s’en trouve, notamment par les demandes formulées par des utilisateurs d'iceScrum.

Voir aussi