Améliorer la performance de votre flux avec les limites de WIP

La Méthode Kanban IT met en avant 6 pratiques que nous avons décrits dans l’article La Méthode Kanban IT (Partie 1) – Initiation.

La seconde pratique préconise de limiter le travail en cours (Work In Progress – WIP) afin d’éviter les goulets d’étranglement et adapter l’encours à la capacité à faire de l’équipe.

Dans cet article nous allons analyser a quoi servent les limites de WIP et comment les calculer.

Des limites pour quoi faire ?

La mise en place de limites de WIP (Work In Progress) est une pratique clé de la méthode Kanban IT. Les limites permettent de contrôler le flux de travail et d’optimiser la productivité de l’équipe.

Les limites permettent à la fois de s’assurer qu’il n’y a pas trop d’éléments dans l’encours, par rapport à la capacité à faire de l’équipe, mais également qu’un nombre minimum d’élément est présent, afin de permettre un continuité de service.

Bien que limiter l’encours d’un flux peut paraitre contre-intuitif, cela apporte des avantages indéniables :

  1. Réduction des goulets d’étranglement : En limitant le nombre de tâches en cours, vous pouvez identifier plus facilement les étapes du processus qui ralentissent le flux de travail. Cela permet de concentrer les efforts d’amélioration sur ces points précis.
  2. Amélioration de la qualité : Avec moins de tâches en cours, les membres de l’équipe peuvent se concentrer davantage sur chaque tâche, ce qui réduit les erreurs et améliore la qualité globale du travail.
  3. Réduction des délais : En limitant le WIP, vous réduisez le temps d’attente entre les étapes du processus, ce qui accélère la livraison des tâches.
  4. Meilleure collaboration : Les limites de WIP encouragent la collaboration et la communication au sein de l’équipe, car les membres doivent travailler ensemble pour respecter ces limites.
  5. Flexibilité et adaptation : Les limites de WIP peuvent être ajustées en fonction des besoins et des capacités de l’équipe, permettant une adaptation continue du processus

Comment mettre en place des limites de WIP ?

L’identification et le mise en place de limites de WIP n’est pas une science exacte et dépend de plusieurs facteurs, notamment de la taille de l’équipe, la complexité des tâches, les contraintes techniques et organisationnelles et la capacité de travail de chaque membre.

Au lancement de votre Système Kanban

La première étape à suivre, avant de mettre en place des limite de WIP est de bien cartographier et rendre visible le flux de création de valeur de votre Système Kanban.

Vous devez ensuite évaluer la capacité de l’équipe en estimant le nombre de tâches que votre équipe peut raisonnablement gérer en parallèle sans compromettre la qualité.

Lorsque vous débutez sur un nouveau flux ou une nouvelle équipe, il peut être tentant de définir des limites de WIP, sans avoir le moindre historique de données.

Une pratique non officielle peut être de définir « arbitrairement » les limites de WIP, en se basant sur le nombre d’intervenant sur chaque étape du flux :

  • Limite haute d’une étape : [Nombre de personne dans l’étape * 2] – 1
  • Limite basse d’une étape : [Nombre de personne dans l’étape] – 1

La limite porte, à la fois, sur l’étape active et le buffer de l’étape.

Exemple : Vous avez une équipe de 5 développeurs. Comment calculer les limites de l’étape « CODING« , découpée en 2 sous-colonnes « CODING WIP » & « CODING DONE » ?

  • Limite Haute = 5* 2 – 1 = 9 tickets maximum sur l’étape CODING
  • Limite Basse = 5-1 = 4 tickets minimum sur l’étape CODING

Imaginons maintenant que les développeurs doivent également effectuer des activités de revue du code, via l’étape « CODE REVIEW« , découpée en « REVIEW WIP » & « REVIEW DONE« . Dans ce cas, le fait d’appliquer cette formule sur l’étape « CODING » et l’étape « CODE REVIEW » peut provoquer une surcharge d’activité et des goulets d’étranglement :

  • Limite Haute CODING = 5* 2 – 1 = 9 tickets maximum sur l’étape CODING
  • Limite Basse CODING = 5-1 = 4 tickets minimum sur l’étape CODING
  • Limite Haute CODE REVIEW = 5* 2 – 1 = 9 tickets maximum sur l’étape CODE REVIEW
  • Limite Basse CODE REVIEW = 5-1 = 4 tickets minimum sur l’étape CODE REVIEW

Dans ce cas, une façon de faire pourrait être de répartir l’équipe de développeurs sur les 2 activités :

  • Limite Haute CODING = 2.5* 2 – 1 = 4 tickets maximum sur l’étape CODING
  • Limite Basse CODING = 2.5-1 = 1.5 arrondi à 1 ticket minimum sur l’étape CODING
  • Limite Haute CODE REVIEW = 2.5* 2 – 1 = 4 tickets maximum sur l’étape CODE REVIEW
  • Limite Basse CODE REVIEW = 2.5-1 = 1.5 arrondi à 1 ticket minimum sur l’étape CODE REVIEW

Comme je l’ai déjà dit, cette méthode n’est pas « officielle » et ne permet pas toujours de tenir compte des contraintes du flux, mais elle reste une première étape dans la mise en oeuvre de limites de WIP et doit surtout être temporaire.

Vous pouvez aussi décider de ne mettre en place aucune limite de WIP, le temps de recueillir suffisamment d’historique sur le traitement du flux, vous permettant de baser vos limites de WIP sur les contraintes réelles de votre Système, en définissant toutefois une règle simple : « Un membre de l’équipe ne peut traiter qu’un ticket à la fois et un ticket ne peut être pris que lorsqu’un membre de l’équipe est disponible ».

Après quelques semaines et des données …

Voila maintenant 2 à 3 semaines que votre flux est opérationnel. Vous utilisez une application digitale comme Flow Analytics Pro, vous permettant de mesurer et analyser la qualité de votre flux, que vous soyez en Scrum, Kanban, SAFe ou un autre framework Lean/Agile.

Voici un méthode, toujours non « officielle », que vous pouvez utiliser pour mesurer les limites de WIP, hautes et basses.

Partons du cas réel d’une équipe de développement.

1 – Elle mesure le WIP, sur chaque étape de son Flux Kanban, sur un mois (20 jours ouvrés en février 2025).

2 – Elle calcule ensuite le WIP moyen, sur chaque étape de votre flux

3 – Ainsi que l’écart-type de chaque étape de votre flux

4 – L’équipe applique ensuite la formule suivante pour calculer la limite haute de chaque étape du flux

Limite Haute = WIP Moyen + 1.5 * Ecart-Type

5 – Ainsi que la formule pour calculer la limite basse de chaque étape du flux

Limite Basse = WIP Moyen – Ecart-Type

6 – L’équipe doit également tenir compte de ses contraintes et ajuster les limites

La mesure ayant lieu sur le dernier mois, vous devez tenir compte des nouvelles contraintes de l’équipe, afin d’ajuster vos limites de WIP. Par exemple, lorsque l’équipe perd 1 développeur.

Ajuster en continu : Les limites de WIP ne sont pas figées. Surveillez régulièrement le flux de travail et ajustez les limites en fonction des performances de l’équipe et des changements dans le processus.

Conclusion

Les limites de WIP sont un outil puissant pour améliorer la performance de votre équipe et optimiser votre flux de travail. En les mettant en œuvre de manière réfléchie et en les ajustant en continu, vous pouvez réduire les goulets d’étranglement, améliorer la qualité et accélérer la livraison des tâches. N’hésitez pas à expérimenter et à adapter ces limites en fonction des besoins spécifiques de votre équipe et de votre projet.