Tomas Rybing, directeur de la gestion de projet chez Aptilo Networks, partage dans son dernier billet le concept d'un tableau kanban nommé "Arrow" (flèche - NdT). La Flèche s'appuie sur l'approche de pyramide de priorisation. La flèche est une visualisation du backlog combinée à un tableau kanban qui matérialise le processus de travail.
Tomas a ajouté une pyramide de priorisation tournante comme point d'entrée du tableau kanban avec plusieurs lignes. L'exemple ci-dessus en a trois. Les lignes servent à limiter le travail en cours (WIP).
Combien de lignes devriez-vous avoir ? Cela dépend de la taille de votre équipe et de l'efficience attendue de votre flux. Une ligne vous donne l'efficience de flux la plus forte, les équipes ne travaillant que sur une "story" à la fois. Cela n'est pas toujours pratique ; différents membres de l'équipe seront inoccupés à différents moments. Un conseil simple est d'avoir moins de lignes que de membres dans l'équipe pour favoriser la collaboration.
Tomas a ajouté une DoD (Definition of Done) écrite avec les critères à respecter avant qu'une tâche ne passe à l'étape (colonne) suivante. Voyez le comme une check-liste à remplir avant de bouger la tâche. Utiliser une telle approche évitera l'avancement des tâches dans le processus sans l'attente des pré-requis.
Tomas a aussi transformé la colonne "Done" en une flèche.
Normalement, les cartes sont enlevées de la colonne “Done” quand celle-ci est pleine (de même qu'avec Scrum où le tableau est "nettoyé" avant le début de chaque sprint). Mais pourquoi ne pas pointer avec la flèche vers un espace permettant de montrer plus de cartes afin de voir nos réalisations sur une plus longue période ! De la sorte, vous pouvez compter vos cartes sur une période plus grande et les lier à des évènements particuliers. Par exemple, "quand nous aurons atteint 50 cartes en Done, nous fêterons cela avec un gateau" (limite gateau). Toutes les vingt cartes en Done (20, 40, etc), faîtes une rétrospective, etc.
Une affiche est présente devant la flèche avec les objectifs de l'équipe. Ils devraient être écrits de sorte à guider l'équipe dans le quotidien.
Tomas explique le flux des "stories" dans le arrow kanban board dans sa présentation disponible sur SlideShare.
Il partage son expérience avec ce format :
- Nous n'avons pas mis de règles sur la ligne urgence, et sans surprise, la majorité du travail atterit là au début. Une incertitude se dessinait lorsque le travail était "assez important" pour ne pas prendre les lignes standards, et dès lors se retrouvait en ligne urgence car il n'y avait pas d'autre place. Cela se résout en posant des règles sur cette ligne urgence, et en ayant des critères sur l'usage des lignes normales.
- Comme les lignes restreignent maintenant les conditions de démarrage du travail (c'est-à-dire seulement quand une ligne est disponible), les membres de l'équipe sont plus souvent bloqués. Nous avons expérimenté des "lignes lentes" pour le travail de moindre priorité qui peut être pris (et laissé) facilement, quand un membre est bloqué temporairement sur une tâche principale.
- Nous avons une section "prêt à montrer" en dehors de la flèche, où les tâches finies sont montrées durant la démo hebdomadaire. S'il n'y a pas de tâches, la démo est reportée à la semaine suivante.
David J. Anderson, PDG de David J. Anderson & Associates, auteur, formateur Kanban & Consultant, commente l'idée du tableau flèche de la manière suivante :
Le triangle de priorisation est une idée intéressante pour les organisations à faible maturité qui manquent de discipline et qui ont besoin d'une contrainte physique pour limiter le WIP.