Comment réguler le flux dans notre Kanban
“On utilise un Kanban dans l’équipe pour suivre nos Userstories. Mais, nous n’arrivons pas toujours à rendre notre Delivery fluide, si bien que nous avons très souvent un stock de Userstories bloquées !” — Un Product Owner.
Des Userstories bloquée dans un Kanban ? L’équipe travaille sur trop de tâches qu’elle ne pourra finaliser, avec le risque de devenir obsolètes lorsqu’elles seront reprises.
Alors, comment faire pour éviter ce gaspillage et avoir un Delivery plus fluide ?
Mais avant, un Kanban, c’est quoi ?
La méthodologie Kanban a été créée par Taiichi Ōno pour Toyota en 1950 dans le but d’optimiser la capacité de production de l’entreprise. Il s’agit d’une méthode de gestion des stocks qui sert à produire sur demande (le fameux “Just in time”) pour :
- Réduire les coûts de production,
- Éviter les gaspillages liés à la surproduction ou à une production inadaptée,
- Diminuer les délais de production.
Qu’est-ce que “la fluidité” d’un Kanban ?
Tout comme le débit d’un liquide, l’écoulement de tâches dans notre Kanban suit exactement la même loi : la “Loi de Little”. Elle est issue de la théorie des files d’attente, qui décrit la relation entre le temps d’attente, le stock, et le débit.
Dans cet exemple, on constate que, même si le débit est élevé dans les premières cuves, il existe un goulot d’étranglement au niveau de la cuve 3.
Le débit global dépendra donc du débit de cette dernière.
Ce qui a été versé dans les cuves précédentes est alors une forme de gaspillage :
- Le liquide peut stagner et le rendre impropre à la consommation,
- Certaines cuves pourraient déborder et donc perte leur liquide.
Bref, on verse trop par rapport à la capacité globale des cuves !
Pour éviter tout gaspillage, nous aurions plusieurs choix :
- Verser moins de liquide … Jusqu’à même imaginer la solution radicale : une fermeture du robinet.
- Réguler le débit des cuves, en augmentant le débit de la cuve 3 ou en mettant en place un système de sécurité “anti-débordement”.
Nous aurons exactement cette même réflexion pour le Kanban.
Prenons l’exemple d’une équipe pour illustrer cet article
Vous vous souvenez du Product Owner et d sa problématique ?
Le problème : “On utilise un Kanban dans l’équipe pour suivre nos tâches. Mais nous n’arrivons toujours pas à rendre fluide notre Delivery, si bien que nous avons très souvent un stock de Userstories bloquée.”
Voici la constitution de cette équipe que nous appellerons “John Doo” :
- 1 Product Owner.
- 10 Développeurs.
- 1 testeur.
Leur Kanban est le suivant :
Comment retrouver “leur cuve limitante” ?
L’équipe John Doo mesure l’écoulement moyen (ou débit) de ses tâches en fonction d’une unité de temps (la semaine pour notre exemple), représenté par une ligne horizontale sur le graphique.
- Conception terminée = 3 tâches par semaine,
- Développement terminé = 3 tâches par semaine,
- Test terminé = 2 tâches par semaine,
Cela pourrait être interprété de cette façon suivante :
La 3ème cuve (la phase de Test) est leur “cuve” limitante. En moyenne, chaque semaine, 3 tâches entrent dans le Kanban et uniquement 2 en ressortent.
Pour en savoir plus : Série “les indicateurs d’équipe” : le débit | by Silvere Duval | Just-Tech-IT | Medium
Quelle analyse peut-on en faire ?
L’équipe John Doo a analysé que :
- La 3ème cuve (la phase de Test) détermine le débit global du Kanban,
- Il existe une zone de stockage de tâches au niveau de la phase de Développement.
On voit très distinctement l’accumulation de tâches en regardant leur Diagramme de flux cumulés, avec un écart qui se creuse chaque semaine entre les développements et les tests.
L’équipe semble travailler en silos. Chacun travaille de son côté, sans se soucier de ses voisins. Le Product Owner écrit ses Userstories. Les développeurs développent et le Testeur arrive tant bien que mal à gérer les Userstories qui s’accumulent chaque semaine.
L’équipe risque le débordement si elle n’agit pas maintenant !
Mais alors, comment éviter ce débordement ou comment le réduire ?
Plusieurs solutions s’offrent à l’équipe John Doo :
- Ajuster le “débit des cuves” : en renforçant l’équipe de test (avec nouveau testeur ou un membre de l’équipe),
- Limiter le travail des membres pour prévenir tout goulot d’étranglement.
Et si on limitait le travail sur en-cours (ou Work In Progress/WIP) ?
Sur chaque colonne d’un Kanban, l’équipe déterminera des limites minimales et maximales du nombre de tâches permettant de prévenir de futurs goulots d’étranglement. Cela deviendra son système de sécurité anti-débordement.
La décision de l’équipe
L’équipe a défini les critères suivants pour prendre une décision :
- 1 seule tache en cours pour chaque développeur,
- Réduire le nombre de tâches bloquées,
- Conserver ou améliorer le débit de l’équipe.
En fonction de ces critères, l’équipe a décidé d’appliquer les limites suivantes :
- En Tests : Comme il s’agit de la dernière étape, l’équipe a considéré qu’il n’était pas nécessaire de définir de limite.
- En Développement : L’équipe a décidé de s’adapter au débit du testeur pour réduire au maximum le nombre de Userstories en attente. Ils se sont donné une limite maximale de 4 dans la colonne “Développement terminé” car, d’après les indicateurs, le testeur ne pouvait traiter pas plus dr 4 Userstories maximum.
En Conception : Le Product Owner délivre en moyenne 3 Userstories par semaine. Il a été décidé d’indiquer la même limite maximale que celle de la phase de Développement, pour un débit identique.
Attention, ce choix est propre à cette équipe. D’autres équipes auraient pu faire un choix différent !
Comment utiliser ce système dans le Delivery ?
Maintenant, l’équipe va expérimenter ses limites.
Connaissez-vous la notion de flux tiré ?
En Kanban, le travail est déclenché en aval. C’est ce que l’on appelle le “flux tiré”.
Dans l’exemple de l’équipe John Doo, une tâche de test est terminée. Le Testeur est donc disponible pour “tirer” une nouvelle tâche de la colonne “Développement Terminé”.
Pour en savoir plus : Flux poussé VS Flux tiré. On entend souvent parler de flux tiré… | by Silvere Duval | Just-Tech-IT | Medium
Un rappel de comment cela se passait avant les limites …
L’équipe constatait très souvent un stock conséquent de tâches bloquées que le testeur,en bout de chaîne, n’arrivait pas à gérer.
… Et maintenant, grâce aux limites sur en-cours
En Daily, l’équipe analyse le Kanban en Daily et ses limites par colonne. Un problème apparait ? L’équipe lance immédiatement des actions pour le résoudre !
Le cas passant, tout va bien !
Tout va bien, tout le monde est occupé. Aucune colonne n’a dépassé la limite.
Un cas non passant ? Le système de sécurité anti-débordement est activé.
Une tâche vient d’être développée, pourtant, avec les limites sur en-cours, elle ne pourra pas être déplacé dans la colonne “Développement terminé” :
- Le testeur n’est pas disponible pour prendre une nouvelle tâche,
- La colonne “Développement terminé” a atteint sa limite haute,
- La colonne “Développement en cours” a atteint sa limite haute.
D’autre part :
- Aucune nouvelle tâche ne pourra être développée,
- Le stock de tâches est limité et maitrisé (6 tâches au total = 2 en “Conception terminée” + 4 en “Développement terminé”).
L’équipe a décidé, en Daily, que le développeur disponible aiderait temporairement le testeur pour réduire le stock de tâche et fluidifier de nouveau le Delivery.
Une Rétro, pour le mode test and learn
L’équipe John Doo bouge ! Le Product Owner vient de terminer sa mission et une nouvelle personne est en train de monter en compétence sur le poste.
En Rétrospective, l’équipe a anticipé la baisse temporaire du débit de Conception et a décidé de réduire de 10 à 9 la limite de Développement pour permettre à chaque développeur disponible de former le nouveau Product Owner.
L’équipe n’hésite pas à faire une Rétrospective spécifique sur les limites sur en-cours pour les adapter régulièrement si nécessaire.
- Les limites sont toujours dépassées ?
- Le débit s’est amélioré ?
- L’équipe s’est réorganisée ? De nouveaux membres sont arrivés ?
Un réflexe : la revue des limites sur en-cours !
En conclusion
Ajouter des limites sur en-cours permet à l’équipe :
- De maitriser et fluidifier son Delivery,
- De mieux travailler ensemble en s’entre-aidant,
- Que ses membres deviennent polyvalents,
- De bénéficier d’un temps pour l’amélioration continue, la documentation, se former, la participation à des ateliers collaboratifs, les Communautés de Pratiques, la créativité … etc.
Et contrairement à ce que l’on pourrait penser, aucun membre de l’équipe ne restera inactif. Bien au contraire !
Sources de cet article
Comment éviter le gaspillage dans vos projets ? | by Silvere Duval | Just-Tech-IT | Medium
Série “les indicateurs d’équipe” : le débit | by Silvere Duval | Just-Tech-IT | Medium
Et si vous contrôliez votre WIP (Work In Progress) ? | by Silvere Duval | Just-Tech-IT | Medium
