Sabrina Ferlisi Cet article vise à provoquer une prise de conscience sur notre manière de travailler, que ce soit au niveau du portfolio, des projets ou des équipes. En particulier, maîtriser le travail en cours à un niveau stratégique, comme le portfolio, a un impact significatif sur l’ensemble de l’organisation.
Si vous manquez de temps je vous invite soit :
- A minima à lire la conclusion au paragraphe : Prioriser sans maîtriser la quantité de travail en cours et la taille, une illusion ?
- Regarder la vidéo 👇
La priorisation est souvent au cœur des stratégies de planification dans la gestion de projet. Pourtant, dans n’importe quel environnement de travail, la priorité des éléments peut rapidement perdre son sens si l’équipe ne maîtrise pas le nombre de travaux en cours (Work In Progress ou WIP) et la taille des éléments traités.
Cet article vous explique pourquoi prioriser ne sert à rien si votre WIP est trop grand, en s’appuyant sur des simulations à l’aide de la méthode Monte Carlo.
Rappel rapide sur Kanban et les métriques
Kanban est une stratégie d’optimisation du flux de valeur à travers un processus utilisant un système de visualisation des systèmes de flux-tirés. La notion de flux tiré consiste à ne commencer un travail que lorsqu’une demande est exprimée, par opposition à un flux poussé où le travail est planifié et lancé indépendamment de la demande réelle. Cela permet de mieux gérer la capacité de l’équipe, d’éviter les surcharges et de garantir un flux de travail fluide et optimisé.
Quatre métriques importantes se dégagent :
- le WIP : Work In Progress, le travail en cours,
- le Cycle Time : temps qu’un élément met à être traité de bout en bout,
- le Throughput : le débit en français. Le nombre d’éléments complétés sur une période donnée,
- le Work Item Age : l’âge des éléments en cours de traitement.
Ces métriques sont essentielles pour comprendre le fonctionnement et l’efficacité du flux de travail.
Pour ceux qui souhaitent en savoir plus sur ces métriques et leur importance, je vous invite à consulter cet article précédemment publié, qui parle de l’utilisation de Kanban dans Scrum. Cependant, les principes abordés restent valables pour du Kanban « pur ».
Simulations Monte Carlo : comment ça marche ?
Les simulations Monte Carlo sont des modèles statistiques utilisés pour évaluer les probabilités de différents résultats en se basant sur des données historiques. Dans le contexte de Kanban, elles permettent d’estimer la probabilité de terminer un ensemble d’éléments avant une date donnée. Contrairement aux estimations traditionnelles, souvent imprécises, ces simulations fournissent une meilleure visibilité en exploitant les performances passées de l’équipe.
Un exemple concret
Prenons l’exemple de l’équipe A, dont le débit (nombre de items terminées par jour) a été mesuré sur 15 jours.
Les résultats montrent des variations significatives, allant de 0 item terminée certains jours à 5 items d’autres jours. Ces données reflètent les capacités fluctuantes de l’équipe.
En utilisant les données de débit, la simulation Monte Carlo sélectionne aléatoirement un jour parmi les données historiques et attribue ce débit à une journée future. Ce processus est répété des milliers de fois.
Par exemple, lors d’une simulation, le jour 15 (avec un débit de 5 items) pourrait être sélectionné, suivi du jour 4 (0 item). En répétant ce processus sur 10 000 simulations, nous obtenons une distribution des résultats possibles.
Dans cet exemple, l’équipe a une probabilité de 94.1% de terminer 35 items avant la date donnée. Cette information permet d’anticiper les délais avec une grande fiabilité, en se basant uniquement sur les performances passées.
L’impact du WIP sur la probabilité de terminer les éléments à temps
Maintenant que les bases ont été placées, voyons comment le WIP (Work in progress, le travail en cours) et la taille des éléments ont une influence sur la priorisation.
Voici une liste de 10 éléments priorisés avec des tailles variables. Imaginons qu’il s’agit de 10 Features. La première Feature contient 10 User stories, la deuxième Feature contient 5 User Stories, etc. Tous ces éléments doivent être terminés pour le 5 janvier 2025.
Nous allons à présent calculer la probabilité que ces Features puissent être terminées pour la date donnée.
WIP = 1
Si nous lançons Monte Carlo sur cette liste pour une équipe travaillant sur un seul élément à la fois, nous obtenons les probabilités suivantes :
Priorisation fortement respectée : Nous observons logiquement que les premiers éléments de la liste ont une forte probabilité très élevées de terminer à temps. Ce qui va se passer est que l’équipe va travailler sur l’élément A1. Quand l’élément A1 est terminé, elle va démarrer l’élément A2, etc.
Par exemple, A1 (taille 10) a une probabilité de 99.99%, A2 (taille 5) est à 99.98%, et A3 (taille 10) est à 95.53%. L’équipe est donc capable de terminer les éléments en respectant l’ordre des priorités.
WIP = 3
Augmentons le nombre de travail en cours en parallèle pour l’équipe à 3 éléments.
Cette fois, nous remarquons que les éléments de plus petite taille ont des probabilités plus élevées d’être terminés : Les éléments A2 et A4, qui ont une taille de 5, sont parmi ceux qui ont la plus forte probabilité de terminer dans les délais (98.93% pour A2 et 80.93% pour A4). Cela montre que les éléments plus petits sont plus susceptibles d’être terminés, même si leur ordre de priorité n’est pas en tête de liste.
Les priorités peuvent être difficiles à respecter : En raison de la taille des éléments et de la limitation du WIP, les priorités définies initialement ne sont pas systématiquement respectées. Par exemple, A1 a une probabilité de 77.37%, tandis qu’A2, bien que moins prioritaire, a une probabilité beaucoup plus élevée de 98.93%. Cependant, les éléments qui ont le plus de chance d’être terminés se trouvent au moins dans la moitié haute de la liste.
WIP = 7
Augmentons le nombre de travail en cours en parallèle pour l’équipe à 7 éléments.
La probabilité de terminer les éléments est globalement faible, même pour les éléments de petite taille. Par exemple, l’élément A2 (taille 5) a une probabilité de 62.41%, tandis que A1 et A3 (taille 10) ont des probabilités très faibles, respectivement 6.72% et 6.78%. Cela montre qu’avec une WIP plus élevée, la capacité à respecter les priorités devient beaucoup plus incertaine.
Les petits éléments sont mieux placés, mais pas assurés : Contrairement au cas précédent avec une WIP plus basse, les petits éléments (comme A2, A4, et A5, tous de taille 5) ont des chances relativement meilleures d’être terminés, avec des probabilités entre 61% et 62%. Toutefois, même ces probabilités sont loin d’être assurées, indiquant une instabilité due à une WIP trop grande.
WIP = 10
Enfin, augmentons le nombre de travail en cours en parallèle pour l’équipe à 10 éléments. Toutes les features sont démarrées en même temps.
Avec une WIP de 10, la probabilité de terminer chaque élément dans les délais est généralement très faible, sauf pour les deux plus petits éléments (A8 et A10). Par exemple, l’élément A1 (le premier de la liste !) n’a que 2.89% de chances d’être terminé dans les délais. Cela montre qu’avec un WIP élevé, il est difficile pour l’équipe de se concentrer efficacement, ce qui réduit la probabilité de terminer les éléments.
Petits éléments toujours favorisés : Les éléments A8 (taille 3) et A10 (taille 2) ont les meilleures probabilités de terminer dans les temps (77.7% et 90.98% respectivement). Cela est dû à leur petite taille, qui les rend plus rapides à compléter par rapport aux autres éléments, même dans un contexte de WIP élevé.
Prioriser sans maîtriser la quantité de travail en cours (WIP) et la taille, une illusion ?
Les simulations montrent clairement que prioriser est inefficace si l’équipe ne maîtrise pas sa quantité de travail en cours (WIP). Quand le WIP est trop élevé, la priorisation n’a plus d’impact, car la taille des éléments devient le facteur déterminant de leur achèvement. Cela signifie que, malgré tous les efforts pour définir les bonnes priorités, celles-ci seront inévitablement ignorées si le flux de travail est saturé et mal contrôlé. En conséquence, le véritable levier réside dans la maîtrise du nombre de travaux en cours.
Ainsi, avant même de consacrer du temps à la priorisation, il est crucial de vérifier si votre équipe maîtrise son WIP et si la taille des éléments est adaptée. Sans cela, la priorisation devient une perte de temps. Une bonne gestion du WIP, associée à un « right sizing » des éléments de travail, est la clé pour rendre la priorisation efficace et pour faire avancer les projets de manière prévisible et cohérente.
Avant de vous concentrer sur les priorités, posez-vous la question : est-ce que mon équipe maîtrise vraiment son WIP et travaille sur des éléments de la bonne taille ?
C’est bien sympa, mais on fait comment pour maîtriser son WIP ?
Maîtriser son WIP peut être contre-intuitif, mais cela est essentiel pour améliorer le flux de travail et assurer le respect des priorités. Voici quelques étapes pour commencer :
- Lire le Kanban Guide : Le Kanban Guide est une ressource incontournable pour comprendre les principes fondamentaux de Kanban et les bonnes pratiques liées à la limitation du WIP. C’est un excellent point de départ pour toute personne souhaitant mieux maîtriser son processus de travail.
- Sensibiliser son équipe (à tous les niveau : Portfolio, Projet ou Produit) : La maîtrise du WIP commence par une sensibilisation de l’équipe. Tous les membres doivent comprendre l’importance de limiter le nombre de travaux en cours. Il est important de noter que le WIP peut être maîtrisé à différents niveaux (équipe, projet, ou même portefeuille). Plus il est maîtrisé à un niveau stratégique, comme le niveau portfolio, plus son impact sera significatif.
- Venir se renseigner auprès de moi : Si vous souhaitez aller plus loin, je suis disponible pour vous aider et aiguiller dans la mise en place de pratiques Kanban et vous aider à maximiser l’efficacité de votre équipe. N’hésitez pas à me contacter pour en discuter davantage.
Un grand merci à ProKanban et ActionableAgile pour la mise à disposition des outils qui ont permis d’illustrer cet article.
