Flux poussé VS Flux tiré
On entend souvent parler de flux tiré et de flux poussé car il s’agit d’une des bases essentielles du Kanban et du Lean. Mais en connaissez-vous le sens ?
Le flux tiré (ou pull system)
La notion de flux tiré provient de Toyota, à travers son “Toyota Production System”.
“Le système de production Toyota (Toyota Production System — TPS) est conçu de manière à “tirer” le produit fini d’un bout à l’autre de la chaîne de production.” — Source : www.toyota.fr
Qu’entend-on par “Flux tiré” ?
Si l’on s’adapte à nos projets, le flux tiré consiste en un tirage de cartes de gauche à droite dans notre Kanban par les personnes intervenant le plus à droite du kanban.
Prenons l’exemple du Kanban suivant qui appartient à une Squad, en se concentrant tout d’abord sur Alain, un développeur de cette squad.
Nous sommes le 8 décembre et Alain a indiqué lors du daily du matin que la Userstory dont il avait la charge était terminée (Definition of Done) et qu’il était disponible pour développer une nouvelle carte.
Cette Userstory a été placée dans la colonne “Développer — Fin”.
Un atelier 3 Amigos est donc prévu dans la journée avec Alain, Magali (la testeuse) et Julien (le Product Owner).
Pendant le 3 Amigos, Alain tirera la prochaine Userstory qui est celle qui se trouve dans la colonne “En conception” et dont la business value est la plus forte (Definition of Ready).
Il faut donc que Julien anticipe bien la fin de conception des Userstories pour qu’au moins une Userstory soit toujours disponible.
Du point de vue de l’affichage dans le Kanban, la Squad a décidé que les tickets seraient triés de façon décroissante en fonction de leur Business value. Ainsi, le ticket avec la plus forte valeur ajoutée Métier se trouvera en haut de la colonne “En Conception”.
A la fin du 3 Amigos, la Userstory se retrouvera donc dans la colonne “Développer — En cours” et elle appartient maintenant à Alain.
On remarque ici que chaque développeur doit être sur un seul ticket en cours et non sur plusieurs pour que le flux tiré fonctionne.
Une fois cette Userstory développée, Magali va donc la tester en Pair-test, une fois que la Userstory en cours de pair-test sera terminée.
Tant que Magali ne sera pas disponible, la Userstory ne pourra pas être déplacée dans une colonne suivante.
Dans le flux tiré, chaque personne se met d’accord avec la personne qui va suivre. On travaille en équipe pour réussir ensemble à satisfaire le Métier/client.
Comment se passe un flux tiré en cas d’urgence
Il nous arrive d’avoir des urgences pendant la vie d’une Release (anomalie de production, un nouveau besoin Métier …).
Prenons l’exemple d’une anomalie de Production.
Une pré-analyse a déjà été faite par Julien, le Product Owner de la squad.
Pendant le daily, la squad a été informée de l’anomalie qui a été priorisée avec le Métier par rapport à la Userstory et le bug en cours de développement. Alain s’est proposé pour son analyse technique et sa (possible) correction
Alain a bloqué la Userstory qu’il était en train de développer (visualisable via un changement de couleur sur le Kanban).
Il est donc prêt à tirer la carte de Bug (qui a été placée dans la ligne d’eau d’urgence). Alain ne devient donc responsable que d’une carte en cours dans le kanban.
Le flux poussé (ou push system)
A l’inverse du flux tiré, dès que chaque personne termine son activité sur son ticket, elle la pousse dans la colonne suivante.
Elle effectue ses activités à son propre rythme, sans trop se soucier de celle qui prendra la suite.
Et c’est à ce moment que la Loi de Little prend tout son sens.
A savoir que le débit de l’ensemble des cuves dépendra de la cuve dont le débit sera le plus faible.
En pratique, cela veut dire que, par exemple, nous pouvons avoir :
- De nombreuses Userstories dont la conception est terminée,
- Un seul développeur,
- De nombreux testeurs.
Le débit dépendra alors du développeur.
(Pour d’autres exemples, le débit pourrait dépendre du Product Owner ou du testeur …)
Dans cet exemple, cela démontre un gaspillage au niveau de la conception car, on a beau préparer des Userstories, dans tous les cas nous ne pourrons pas les prendre toutes.
D’autre part, on remarque que les testeurs seront en sous-activité. Et nous n’imaginons pas la pression et le stress du développeur croulant devant cette montagne de Userstories !!!
Sans oublier l’insatisfaction Métier/client qui n’aura pas ses évolutions avant un certain temps … au risque que son besoin soit obsolète lorsque les évolutions monteront en Production.
Une solution pour le flux poussé : adapter la taille de son équipe en fonction des prévisions besoins métier pour avoir un débit constant à chaque étape du Kanban. Mais, ça, c’est de la théorie !
Pour en savoir plus : Série “les indicateurs d’équipe” : le débit | by Silvere Duval | Just-Tech-IT | Medium
Flux tiré VS flux poussé
Un flux tiré est plus efficace qu’un flux poussé lorsque l’équipe est en Kanban ou Scrumban car il évite le gaspillage et améliore la gestion du stock.
Dans le cas d’une équipe en Scrum, le fait de travailler en sprints courts avec une revue du périmètre avant chaque lancement de Sprint permettent à l’équipe de s’engager sur un petit périmètre et d’avoir un flux tiré efficace.
D’autre part, il va aussi permettre aux équipes d’améliorer la satisfaction Métier/client car, en fonction de la vélocité de l’équipe, il sera possible de prévoir la mise en place des évolutions ayant la plus forte valeur ajoutée et avec un niveau de qualité attendu.
Le flux tiré permet aussi aux collaborateurs de ne se concentrer que sur les tâches à forte valeur ajoutée.
Une technique simple pour démarrer un flux tiré : le daily
Le daily est un moment crucial pour que le développeur ou le testeur indique qu’il a besoin de tirer une nouvelle carte.
Cela permet de responsabiliser chaque membre de l’équipe car chacun connait sa disponibilité et sa capacité à prendre une carte.
