NDLR: WIP = Work in Progress = TEC = Travaux en cours

Mes collègues peuvent facilement m’accuser de ressasser sans cesse la même vieille rengaine. « Il y a trop de travaux en cours! Réduisez votre WIP! »

C’est normal, puisque j’accompagne principalement des équipes qui n’ont jamais eu de mesure de contrôle des travaux en cours. Il n’est pas rare qu’au départ, une équipe possède trois ou quatre fois plus de travaux en cours que de membres dans l’équipe.

Il y a pourtant des occurrences où la réduction des travaux en cours n’est pas la solution. On doit réduire le WIP pour atteindre un niveau soutenable, mais pas en-deçà d’un certain seuil, sinon notre rythme ne sera pas soutenu.

Le principe de la file d’attente

On utilise beaucoup le principe de la file d’attente lorsqu’on enseigne la réduction des travaux en cours. On peut alors aborder le problème de façon mathématique avec des lois démontrées, comme celle de John Little. C’est une approche qui parle peu aux individus normalement constitués.

On peut aussi utiliser des exemples imagés comme celui-ci :

Très clair et très difficile de se battre contre cette démonstration.

Par contre, les deux approches omettent un facteur clé :

La quantité de WIP minimum optimal pour un système dépend entièrement de la nature du travail.

Dans ce vidéo, on peut d’ailleurs remarquer les éléments suivants:

• Le temps de chaque étape est fixe et connu d’avance;
• Le contact entre le client et l’équipe de service est en temps réel;
• La nature du service rendu implique un produit physique;
• Le système commence vide (0 voiture) et se termine vide (0 voiture);
• L’entrée des voitures dans la file se fait selon un rythme constant;
• La manière de produire de la valeur au client ne varie pas dans le temps;
• On voit la portion active du système, mais on ne voit pas l’étendue de la file d’attente dans le stationnement du restaurant.

Alors que dans notre vie, on voit plutôt la situation suivante :

• Le temps de chaque étape est variable et sujet à des contraintes externes;
• Le contact entre le client et l’équipe est en différé et à distance;
• La nature du service rendu implique un produit virtuel;
• Le système n’est pas vide et on ne videra probablement pas le backlog;
• Les demandes arrivent de manière non constantes selon des facteurs externes (saison, fermeture d’année fiscale, vacances, etc.)
• Les outils et nos façons de faire évoluent en continu;
• La demande excède presque toujours notre capacité à produire.

Il est donc tout à fait normal que la limite de WIP optimale pour votre situation soit:

• Contextuelle;
• Variable dans le temps;
• Adaptée au client;
• Évolutive.

Quelques exemples

J’ai rencontré des administrateurs de systèmes (SysOps) qui pouvaient gérer 15 à 20 tâches en simultané, puisque la nature de ces travaux consistait à exécuter des scripts et attendre la fin de leur exécution.

J’ai travaillé avec des designers Web qui perdaient de l’efficacité lorsqu’ils travaillaient sur un dossier client à la fois. Le changement de contexte leur était bénéfique au niveau de l’inspiration.

J’ai vu une situation où un spécialiste était disponible une journée par semaine pour une équipe. Les travaux en amont devaient alors s’accumuler dans une zone de « buffer » pour qu’il ait suffisamment de travaux pour sa journée.

J’ai accompagné une équipe où les clients étaient à distance et devaient régulièrement donner de la rétroaction sur les travaux. Harceler les clients s’est avéré une stratégie peu efficace pour accélérer leur délai de réponse. En augmentant la quantité de travaux en cours, l’équipe a atteint une zone confortable où beaucoup de travaux étaient en attente d’une réponse client. Des règles entourant la fréquence et le nombre de suivis ont été développées.

Je suis moi-même dans un domaine où je suis plus efficace lorsque j’ai plusieurs équipes/ clients/individus à coacher en même temps. Même si je me concentrais sur une seule entité à la fois, le changement ne pourrait pas s’opérer plus vite puisqu’il dépend de la capacité des gens à changer.

Plus on augmente le niveau d’abstraction, plus on peut augmenter le WIP

C’est la même chose lorsqu’on arrête de parler de tâches individuelles et qu’on parle d’initiatives, de projets, de programmes, de stratégies d’entreprise. Il est absurde de penser qu’on peut réduire le WIP jusqu’à ce qu’il ne reste qu’une seule chose à la fois en cours dans l’entreprise au complet.

La nature d’un projet ou d’une initiative par exemple…

• Le démarrage occupe peu de personnes;
• La concrétisation occupe plus de personnes;
• La finalité occupe moins de personnes

…nous oblige à mener plusieurs initiatives de front afin de les imbriquer.

Le parallélisme et l’allocation de capacité sont des stratégies valides

Lorsque plusieurs clients se partagent la capacité d’une équipe, il est souvent plus acceptable de partager la capacité de l’équipe et d’accepter le parallélisme. Dans ce cas, le WIP peut être légèrement augmenté pour assurer une présence constante d’éléments de travail de chaque client en cours. Quand un item est livré à un client, un autre item de ce même client peut entrer dans le système.

Même si le temps de traitement de chaque item en sera augmenté, les clients recevront de la valeur à un rythme constant et plus régulièrement, plutôt que par lot. C’est souvent un compromis acceptable lorsque les clients ne voient pas d’avantage à s’entendre entre eux sur une priorisation unique.

N’ayez pas peur d’alimenter votre système

J’ai constaté dernièrement que lorsqu’une équipe comprend pour la première fois que le surplus de travail est néfaste, elle arrive parfois à un résultat comme celui-ci:

Lorsque je leur indique que les deux premières colonnes sont en manque de travail, les équipes vont parfois répondre « Oui, mais on a suffisamment de travail pour nous occuper à temps plein. »

Bien sûr, elles ont compris que si on débute de nouveaux travaux, on augmente le WIP dans le système et on augmente le temps de cycle.

En contre partie, en refusant d’alimenter le système, l’équipe crée de la variabilité au niveau du débit. Le portrait quelques temps plus tard sera probablement celui-ci:

Dans la quête d’une réduction maximum du WIP, l’équipe crée de la variabilité au niveau du débit et des assèchements du système.

Les limites de WIP devraient être utilisées comme des limites supérieures et inférieures de chaque étape pour que le débit demeure stable dans le temps.

Soutenu et soutenable

Ce qu’il est important de retenir, c’est que le système doit atteindre un rythme stable, soutenable et soutenu. Jamais trop de travaux, jamais pas assez.

Lorsque vous trouverez votre équilibre, votre situation générale s’en trouvera grandement améliorée.