Quelles colonnes à la une ?

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

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. Ca dépend d'où on vient, car l'idée avec Kanban est de représenter le processus actuel, pour l'améliorer.

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. Le voici :

Olivier Azeau présentant 2 ans dans le flux à Montpellier

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.

Commentaires

1. Le lundi 31 décembre 2012, 16:00 par Loïc

Dans notre équipe (de 2 développeurs) nous avons rajoutés 2 colonnes : une "à valider", et une "à intégrer" (merge dans le trunk).

La raison n'est pas que l'équipe ne soit pas multidisciplinaire mais plutôt qu'étant jeunes, la qualité était meilleure après relecture d'où ce besoin. Ainsi le 2ème vérifie qu'il y ait bien assez et les bons tests (unitaires), que l'implémentation est bien la bonne. Il peut donc y avoir plusieurs allez-retours dans une branche à part. Quand cela est satisfaisant il reste donc à intégrer (et relancer une dernière fois les tests).

Une autre solution aurait peut-être été de faire du pair-programming mais cela semblait peu satisfaisant pour la motivation de chacun.
Si vous avez d'autres solutions, je n'en vois pas.