Kanban

January 23rd, 2010 Leave a comment Go to comments

Action = porteur + date

AgileGardener : March 18, 2010 12:05 am : Coaching, Kanban

Pour qu’une action se réalise, il faut un porteur et une occasion identifiée dans le temps.

Pour qu'une action se réalise, il faut un porteur de l'action et une occasion identifiée dans le temps.

Pour qu'une action se réalise, il faut un porteur de l'action et une occasion identifiée dans le temps.

Dans le tableau Kanban, lorsqu’une carte est bloquée, l’équipe à tendance à dire : « Cette carte est bloquée! Elle dépend de X, il faut que je le rappelle [...] mais il n’est pas très disponible. »

Lorsque j’entends ceci, je parie : « dans deux jours, la carte sera toujours bloquée au même endroit! ». D’ailleurs pourqoui changerait-elle de place? Il y a deux jours, la carte était là et j’avais déjà entendu la même excuse phrase, il n’y a donc pas de raison que cela change. Même cause, même effet!

Alors l’équipe me regarde avec de grands yeux et nous entamons un dialogue qui ressemble au suivant :

- moi : « Ok, qui va le faire et quand? ».

- équipe : « Il faut rappeler X, mais il n’est pas très disponible. ».

- moi : « Qui subit l’impact de la carte bloquée? ».

- équipe : « C’est nous! ».

- moi : « Qui a intérêt à ce que la carte soit débloquée? ».

- équipe : « C’est nous! ».

- moi : « Ok, qui va appeler et quand? ».

Certaine fois, je n’ai pas fini de poser la question qu’il y a un volontaire pour prendre la responsabilité de régler le problème dès la fin du daily. D’autre fois la réponse est : « Je n’ai pas le temps maintenant, je regarde mon horaire dès la fin de la rencontre et j’y place cette tâche ».

[Quelques semaines plus tard...]

L’équipe adresse chaque jour les points bloquants avec une action portée par une personne et identifiée dans le temps. Et les cartes bloquées se libèrent ;-)

Êtes-vous toujours attentifs aux : « Il faut que? »

6 Comments »

Mettre de la pression sur le système pour faire apparaître le gaspillage

AgileGardener : March 11, 2010 12:05 am : Coaching, Kanban

Mettre de la pression sur le système pour faire apparaître le gaspillage

Mettre de la pression sur le système pour faire apparaître le gaspillage

Afin de faire apparaître les goulots d’étranglement dans le processus de réalisation d’une équipe fonctionnant en Kanban, j’ai proposé de réduire les limites du WIP[1. Work In Progress]

Lors de la mise en place, l’équipe a fixé des limites confortables pour le WIP. Après deux semaines d’utilisation du tableau, l’équipe n’a pas identifié de goulot d’étranglement.
Lorsque j’ai fait ce constat, j’ai proposé au coordonnateur, lorsqu’il a remodelé le tableau à la réception du nouveau tableau, de réduire la capacité de certaines colonnes en plus des modifications prévues lors de la rétrospective.

Cela va bientôt faire trois mois que le tableau Kanban est en place et deux mois que les limites ont été baissées, et nous avons observé des difficultés telles que les suivantes :

  1. Des cartes sont bloquées depuis plusieurs jours et il ne reste qu’un espace disponible dans la colonne pour passer des nouvelles demandes.
  2. Il y a deux cartes dans une case.
  3. Une case ‘blocage spécial’ à été crée pour sortir une carte qui est bloquée et qui n’est plus prioritaire.

En discutant avec l’équipe, il apparaît que la baisse des limites a eu l’effet escompté, puisque avant cette baisse, il y avait suffisamment de place libre pour que de nouvelles cartes puissent passer même si d’autres étaient bloquées.

Content de ce résultat, je comptais proposer à l’équipe de réduire le nombre global de cartes présentes dans le tableau, car actuellement, les limites établies permettent d’avoir un nombre que « je » juge trop important d’items en cours simultanément.
En effet les limites sont établies par étapes du flux de travail, mais les mêmes personnes travaillent sur plusieurs étapes et cela ne force pas les items à sortir le plus vite possible, certains restant même plusieurs jours dans le backlog.

Mais je me suis ravisé car mes solutions ne seront jamais meilleures que celles de l’équipe.
Alors, au lieu de proposer ma solution de réduction du nombre de cartes dans le tableau, j’ai proposé à l’équipe de travailler sur la notion de gaspillage lors d’une rétrospective.

À la suite de cette rétrospective, après avoir identifié l’attente (une carte est souvent en attente dans le tableau) comme l’un des plus gros poste de gaspillage, l’équipe a commencé à mesurer le temps passé par les cartes dans les différentes phases du processus à l’aide de la méthode proposée dans l’article « Flow. Discover Problems and Waste in Kanban ».
J’espère que ces mesures permettront à l’équipe de trouver « ses » solutions pour éliminer le gaspillage, solutions qui rendront la mienne obsolète.

Quels sont les mécanismes que vous mettez en place pour contraindre le système ? Quels sont les résultats que vous obtenez ?

4 Comments »

Il y a du gaspillage dans l’air!

AgileGardener : March 4, 2010 12:05 am : Kanban

Une carte bloquée dans le tableau Kanban, c'est du gaspillage

Une carte bloquée dans le tableau Kanban, c'est du gaspillage

« Cette carte est bloquée car il nous manque un contenu, un fichier sans lequel le site ne peut être mis en ligne. On sait que ça va prendre plusieurs jours. En fait, on ne sait même pas quand est-ce que ce fichier sera disponible. En plus, cette carte n’est vraiment plus prioritaire ».

Voilà ce que j’ai entendu il y a quelques jours. L’équipe a déjà travaillé sur cette carte, le site est bien avancé. En fait, il ne manque qu’un fichier, mais cela bloque sa livraison et, par effet de bord, une case dans le tableau Kanban, réduisant la capacité à réaliser d’autre demandes.

La première réaction est de dire « le Kanban ne fonctionne pas, ce n’est pas assez flexible ». Il suffit de pousser la carte sur le bord et de laisser la place aux autres items à réaliser.

Holà! Doucement, doucement! Un des objectifs de la mise en place d’un système Kanban, est de rendre visible les gaspillages et de permettre ainsi de prendre des actions pour les endiguer et améliorer le processus.

Donc nous avons un succès, un beau succès, Kanban fonctionne bien! Maintenant qu’est-ce qu’on fait?

Nous pouvons identifier plusieurs gaspillages dont les suivants :

  • Surproduction : l’équipe à passer du temps à produire un site qui ne sortira peut-être jamais
  • Coordination inutile : pendant plusieurs jours, l’équipe a passé du temps à se synchroniser pour cette tâche.
  • Changement de tâche : l’équipe doit laisser une tâche de côté et devra peut-être y revenir, cela nécessitera alors du temps pour se concentrer et reprendre la connaissance.
  • Délai : la carte bloquée empêche d’autres demandes de renter dans le flux, retardant leur livraison.

Ces constatations m’amènent à poser les questions suivantes :

  1. Pourquoi commencer la réalisation d’une carte que l’on ne pourra terminer?
  2. Pourquoi une carte se retrouve-t-elle prioritaire un jour et ne l’est plus, deux jours plus tard, une fois en cours de réalisation?
  3. Pourquoi commencer une carte alors qu’il y en a d’autres bloquées dans le tableau?
  4. Pourquoi commencer une carte alors qu’il y en a en cours de réalisation dans le tableau?

Dans les jours et semaines à venir, je vais aider l’équipe à trouver ses réponses à ces questions et réduire les gaspillages.

6 Comments »

Une colonne “Done” remplie, comme celle de l’équipe Scrum, ça me manque !

AgileGardener : January 4, 2010 12:10 am : Coaching, Kanban

Tableau Kanban de l'équipe "production" (première version)

Tableau Kanban de l'équipe "production" (première version)

Depuis quelques semaines j’ai le plaisir d’accompagner une équipe dans son adoption d’une gestion de projet en mode Agile. C’est un mandat passionnant sur plusieurs aspects :

  • La motivation et l’envie de l’équipe, qui se traduit par un engagement de tous.
  • L’utilisation en parallèle de Scrum et de Kanban qui rend mon intervention en tant que coach intense et très riche.

L’équipe est divisée en deux “sous-équipes” qui ont des rôles et des activités bien différentes : L’une s’occupe du volet production (newsletters, mini-sites, mises à jour de l’existant etc.) et l’autre du volet développement des nouvelles fonctionnalités pour le site Internet.

Suite à nos préconisations, chacune des équipes a choisi d’adopter l’outil qui lui semblait le mieux adapté à ses contraintes : Kanban pour l’équipe production et Scrum pour l’équipe de développement. (Ce n’est d’ailleurs pas le modèle que nous avions proposé en premier lieu)

Au cours de la première itération (l’équipe a choisi des itérations de 2 semaines), en regardant le tableau Scrum de ses collègues, un des membres de l’équipe de production (fonctionnant en Kanban) m’a dit : “Notre tableau ne se vide jamais, ça c’est correct, mais notre colonne “Done” n’est jamais pleine, ça me manque, ça donne l’impression qu’on travaille moins.”

En effet, le tableau Kanban reflétant un flux continu ne se vide jamais comparé au tableau Scrum qui a un cycle de vie de 2 semaines. De plus, l’équipe production vide la colonne “Done” lors  de la mêlée quotidienne après avoir passé en revue les items terminés.

Pour changer cette perception, l’équipe à décider de laisser toutes les tâches à “Done” sur le tableau entre chaque rétropective qui se déroule toutes les 2 semaine . En plus de se donner de la visibilité sur le travail accompli, l’équipe compte utiliser cette pratique pour mesurer plusieurs éléments :

  • Les cartes sont-elles remplies correctements : date de début, date de fin, client, identifiant de la tâche, etc.
  • Le nombre de cartes “urgence”  par 2 semaines.
  • Le temps de sortie moyen par taille d’items.

Votre équipe Kanban a-t-elle déjà eu ce besoin de voir son accomplissement dans le temps ? Qu’avez-vous mis en oeuvre pour cela ?

6 Comments »
« Page 1 »