KANBAN board : encore plus Lean, encore plus Agile

Un Kanban Board

KANBAN est un mot japonais qui signifie étiquette, carte …

ça tombe bien j’utilise beaucoup de cartes et de post-it dans le cadre de mes activités de coach agile !

ça tombe bien Kanban  c’est un des 3 patterns d’accompagnement que je propose: Agile (Scrum) et donc Kanban (ainsi qu’un mix des 2, ScrumBan)

Nouveau ! Découvrez nos services de transformation agile en Suisse ainsi que nos activités de coaching agile / facilitation générative à Genève et Lausanne

Je vous ai déjà parlé du « Radiateur d’informations » (« Information radiator »), représentation selon moi la plus concrète de la culture agile de par son caractère collaboratif, interactif et engageant. Chaque membre de l’équipe sait exactement ce qu’il a à faire.
Le radiateur d’informations est simple, visuel; il suscite intérêt et échanges, même avec le visiteur (votre big boss par exemple) qui peut aisément constater où en est votre projet (avec les burndown / Burnup charts), et examioner d’autres indicateurs. Essentiel donc …

Encore plus intéressant, chaque « Daily scrum » (point quotidien de 15 min) est l’occasion pour l’équipe de le mettre en mouvement : passer une tâche d’un statut à l’autre, prendre une nouvelle tâche…

Et c’est justement là que tout se joue et que l’on va pouvoir mettre en place un des éléments qui a fait le succès de l’approche Lean, le KANBAN, un mécanisme de production en Flux tiré (c’est la demande Client qui déclenche la fabrication par remontée d’ordres).

Concrètement, comment ça marche ?
avec SCRUM (principale Méthode Agile), quelques aménagements et des règles simples:

  • Le projet se déroule sur un mode itératif et incrémental : une realease est découpée en itérations, sprints courts de 2 / 3 semaines maximum (Scrum préconise 30 jours)
  • Le métier (Product Owner) propose les User Stories à implémenter en priorité (= la demande Client, point de départ du flux-tiré)
  • L’équipe et le Product Owner s’accordent sur les User Stories à implémenter sur le Sprint durant la réunion de planification de Sprint
  • L’équipe découpe les User Stories en tâches (= les cartes Kanban) sans se les attribuer (= essentiel !)
  • L’équipe utilise le Kanban Board (mur « habillé  » et divisé en 4 ou 5 colonnes : « To do »; « Ready »; « In progress »; (« To verify »); « Done »), avec au départ toutes les tâches dans la colonne « To do ». Vous l’avez compris, la dimension physique du Kanban Board est primordiale : war room et colocation sont indispensables.
  • L’équipe limitera ses tâches « In Progress », considérés comme des stocks sans valeur et sources de gaspillage au sens Lean et se fixera des règles simples (préférer finir le travail avant d’en commencer un autre; pas plus de n tâches « in progress », selon la taille de l’équipe; pas de cumul de tâches pour un développeur)
  • L’équipe alimentera depuis la colonne « To do », une colonne « Ready » contenant les tâches prioritaires prêtes à démarrer dés qu’une tâche « In progress » passe en « To verify »

Voilà, les principaux ingrédients de notre système à flux-tiré, généré à partir des demandes client, sont mis en place, reste à le faire fonctionner ! C’est le rôle du Daily SCRUM qui alimentera quotidiennement le flux, et fera tourner la mécanique, comme le décrit brillamment Corey Ladas, expert en Lean Software Development :


http://leansoftwareengineering.com/ksse/scrum-ban/

Quels sont les bénéfices à attendre ?

  • Plus de fluidité, une meilleure gestion de la variabilité et réduction des files d’attente
  • Évitement et repérage instantané des goulets d’étranglement
  • Visibilité en temps réel et réactivité
  • Diminution des risques de surcharge
  • Auto-direction et responsabilisation de l’équipe

… On gaspille moins, on fluidifie, on va plus vite, on livre plus vite !

Optimiser les process, augmenter la valeur Client, livrer plus vite des produits de haute qualité, voilà tout l’intèrêt d’associer Lean et Agilité.

Intéressé(e) ? contactez moi pour que nous définissions ensemble les modalités d’une telle association adaptée à votre contexte.

4 Comments

  1. Sébastien Douche
    à

    > Scrum préconise 30 jours

    Hein ? 30/5 = 6 semaines ?! Je présume que la phrase est mal tournée et que c’est plutôt : Scrum préconise 2 à 3 semaines pour une itération, sans dépasser 30j :).

  2. Il faut comprendre "alors que Scrum préconise à l’origine 30 jours", je vais modifier…

    En effet 30 jours, c’est la durée que Jeff Sutherland et Ken Schwaber préconisent pour la durée d’un sprint dans leurs différentes publications et présentations.

    L’idée apportée par Lean Software Development est de raccourcir ce temps, et de le ramener à 2 / 3 semaines max. Mais je te l’accorde, beaucoup d’équipes SCRUM fonctionnent déjà sur des itérations de 2 à 4 semaines. C’est moi même la durée que je préconise

  3. La seul différence que je vois avec Kanban, c’est que le nombre d’étiquette en circulation n’est pas "matériellement" fixe. C’est un élément qui impose quand même de devoir vérifier qu’il n’y a pas trop de tache en cours. Ceci dit, c’est très bon. J’ai bien envie d’essayer. 🙂

  4. Bonjour,

    je ne comprends pas trop en quoi votre taskboard (tableau des tâches) est plus « Kanban » qu’un bon vieux taskboard agiles. La vraie différence entre un « Kanban » (au sens de la méthodologie agile éponyme et pas au sens Lean) et un taskboard agile est que le Work in Progress (WIP) est limité à chaque étape de la chaîne de valeur affichée par le Kanban (chaque colonne).

    La photo est floue mais je crois comprendre que les chiffres en tête de colonne mesure le contenu de la colonne. En Kanban ces chiffres de tête de colonne servent plutôt à mettre une limite au WIP de la colonne.

    Pour ce qui est de la durée des itérations, la méthodologie Kanban ne recommande rien, vous pouvez faire des itérations…ou pas…

    En résumé, Kanban =
    – cartographier le Value Stream Map (i.e. la chaîne de valeur) de votre processus
    – limiter le WIP à chaque étape (c’est ce qui en fait un flux tiré, puisque une étape en amont ne peut pas livrer à une étape aval déjà « pleine ». Pas de contrôle du WIP à chaque étape => flux PUSH).

3 Trackbacks / Pingbacks

  1. Raynald M
  2. Raynald M
  3. Le Wimilab est né ! « Agro-Écologie « from glib import public

Les commentaires sont fermés.