Thread by @Margauxlergo

2ème conf autour du kanban, par Alison Jorre et Nicolas Thibert.
Kanban a pour objectif d'optimiser les délais de livraison. Ce n'est pas une méthode de gestion de projet, ni un cadre agile (vs scrum par ex), ni un tableau de post-it (pas que ça en tout cas). #agilegrenoble

C'est une approche douce de gestion du changement. Commencez là où vous en êtes. Respectez les processus actuels. Changez de manière itérative. Encouragez la prise d'initiatives.

S'appuie sur 5 principes :
1. Visualiser le processus et le travail.
2. Limiter le travail en cours.
3. Expliciter les règles.
4. Mesurer et gérer le flux.
5. Identifier les blocages pour s'améliorer.

1ere étape, qui est l'équipe ?
Ensuite, qui sont les demandeurs et quelles types de demandes font-ils ? Corrections, support, nouvelles fonctionnalités, évolutions... À faire de manière collaborative. Pas toujours si évident à identifier.

Quel est notre flux de travail actuel ? On se demande d'abord comment on estime que le travail est terminé, puis on remonte dans le flux de travail.
Ensuite on pose les sujets en cours sur les étapes identifiées. Ça représente la réalité à l'instant t en rendant tout visibles.

On clarifie et explicite les règles de passage d'une étape à l'autre.
Une fois que tout ça est fait, on peut constater une saturation du système (= trop de tickets dans les colonnes).

La loi de little dit que moins il y 1 d'éléments dans notre système, plus la vitesse de traversée est élevée et le débit est important. Dans kanban, le temps de traversée moyen de chaque élément et le débit sont corrélés au nb d'éléments dans le système.

La théorie des contraintes indique que sur un système, la capacité de prod globale est contrainte par la capacité la plus faible des différentes étapes. Essayer de produire plus en amont ne fait que générer du stock inutilisable.

Bonne pratique : arrêter de pousser des demandes. Ca génère des coûts de maintenance, du multi-tasking, c'est naze. Adopter plutôt un flux tiré en rendant visibles les files d'attente.

Ensuite, il faut contraindre le système pour améliorer l'efficience. Les WIP limit en kanban permettent de réduire l'en-cours sur les postes critiques à plus forte contrainte. 1ère contrainte pour tester : regarder le nb actuel dans une colonne et diviser par 2. L

Le multi-tache coûte en moyenne 17% et jusqu'à 40% du temps productif d'une personne. Plus on a d'en-cours plus on a tendance à faire du multi-tasking. Limiter l'en-cours permet de réduire ce risque.

Mesurer l'efficience de votre système : on mesure le temps de traversée, le débit et le WIP moyen. Le cumulative Flow diagram permet de voir les goulets d'étranglement. Les leviers sont l'orga de l'équipe, de l'entreprise. Redéfinir les WIP limit et les étapes du process.

Définir les cadence du système et implémenter des boucles de feedback. Quand surviennent les évenements (demo, rétro, grooming, chiffrage, injection de nouveaux sujets, triage, livraison...).

Important : avoir des éléments suffisamment petits et homogènes. Si on voit que le temps de traversée est énorme, c'est un signe qu'on n'avait pas découpé assez.
À creuser pour aller + loin : les couloirs de nage (swimlane) pour traiter par ex les urgences.
@AgileGrenoble