Il y a du gaspillage dans l’air!
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 :
- Pourquoi commencer la réalisation d’une carte que l’on ne pourra terminer?
- 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?
- Pourquoi commencer une carte alors qu’il y en a d’autres bloquées dans le tableau?
- 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.
Loading ...
Bonjour,
Après quelques mois de scrum nous sommes passé à Kanban et le premier problème qui se présente à nous c’est justement ce problème de blocage des tâches. Dépendant de plusieurs équipes (nous sommes une équipe spécialisée non une équipe multidisciplinaire à la sauce scrum) de notre spécialisation dépends ce principe de dépendance de l’achèvement de nos tâches en fonction de livraison d’autres équipes internes ou externes.
Nous en sommes venu à ajouter une quatrième colonne à notre tableau Kanban (En attente, BLOQUEE, En cours, A livrer) avec comme principe qu’une tâche bloquée ou à livrer bloquée bascule dans la colonne bloquée, avant de débuter une nouvelle tâche de la colonne “En attente” on vérifie que la condition de blocage d’une tâche de la colonne bloquée n’est pas résolue.
@Lume
Un ami m’a envoyé le courriel suivant relatif à cet billet, et je le partage ici car je pense qu’il apporte à votre commentaire :
Si vos tâches sont bloquées du fait de dépendances, comment faire pour les réduire?
La question peut être abordée selon différentes perspectives : l’organisation des équipes, les compétences des équipes, le découpage ou la répartition des tâches… et beaucoup d’autre encore. L’idée est de repenser la façon dont on travaille une fois que le Kanban a rendu visible les faiblesses du processus.
Je serai curieux de d’apprendre comment vous avez réussi à faire face à ces défis
Bonjour,
Je vous fais un premier retour à la fin de notre second “Sprint Kanban”, j’utilise ce terme car nous avons gardé un certain nombre d’habitude Scrum (planning poker, sprint pour rythmer les rétrospectives et le bilan à destination de notre direction) nous avons dû en abandonner certaines (backlog sprint fixe, product owner, démonstration).
Pour l’heure notre colonne “bloquée” persiste, dans notre process de gestion des tâches nous avons ajouté deux conditions pour qu’une tâche entre dans cet état : un mail de l’intervenant externe dont dépend ce blocage, une date de résolution donnée par cet intervenant externe.
Pourquoi ces tâches sont en état bloquée ?
, qui aujourdh’ui décide des priorités à défaut d’un product owner, de faire une analyse systématique avant de mettre la tâche dans le tableau. Dans le cas d’une correction de bug le temps de cette analyse et le temps de résolution du bug sont très proche (au delta près du process de mise en production).
En première idée j’ai pensé que ces tâches n’auraient pas dû quitter le backlog produit et entrer dans la colonne “En attente” du tableau Kanban tant que toutes les conditions nécessaires à leur réalisation n’étaient pas réunies. Difficile cependant pour le scrum master (moi en l’occurence, juge et partie
Par ailleurs pour une fonctionnalité données qui doit fait l’objet d’un développement dans deux équipes une des tâches va obligatoirement être bloquée dans sa phase d’intégration (et potentiellement dans la phase de développement) car l’autre équipe n’aura pas finit son travail. Soit l’équipe A doit attendre l’équipe B pour valider son développement, soit l’équipe B doit attendre l’équipe A pour utiliser la nouvelle fonction.
Pour des questions de délais on ne peut pas pour autant attendre que la première équipe ait finit avant de commencer le développement dans l’équipe B.
Donc pour l’instant nous conservons cette colonne bloquée qui a cependant l’avantage, avec ces jolis postit orange fluo, de mettre en avant les blocages. Il y a certainement des optimisations à faire dans l’organisation du travail mais ce découpage en équipe spécialisée est en place depuis deux ans pour palier aux problèmes de qualités qui étaient apparus lorsque les mêmes développeurs travaillaient sur toutes les couches de la plateforme.
Cette organisation multiplie les blocages, favorise la déresponsabilisation (c’est pas ma faute c’est les autres qui étaient en retard, y’a toujours un autre en retard avec 7 ou 8 équipes spécialisées) mais il faudrait réorganiser toute la structure du développement sans visibilité sur ce qui en sortirait…
Merci @Lume pour ce retour d’expérience.
J’apprécie votre analyse de la situation et la conclusion sur l’évaporation de la responsabilisation de chacun.
Je ne peux que vous encourager pour affronter le défi de la réorganisation. Effectivement, vous n’aurez pas de visibilité sur ce qui en sortira, mais en aviez vous lorsque vous avez mis en place Scrum?
N’hésitez pas à me contacter si vous avez besoin d’aide (tbalbous – at – pyxis-tech point com)