Un chef de projet qui suit quatre chantiers en parallèle consacre ses journées à basculer d’un contexte à l’autre: relire un compte-rendu, répondre à une demande de clarification, reprendre le fil d’une estimation interrompue deux heures plus tôt. Cette activité donne une impression de productivité, mais le temps réellement consacré à faire avancer chaque projet se réduit à mesure que leur nombre augmente.
Le prix cognitif du changement de contexte
Gerald Weinberg, dans Quality Software Management, a quantifié ce que la plupart des praticiens constatent intuitivement. Avec deux projets simultanés, la perte liée au changement de contexte est d’environ 20%. Avec trois projets, elle atteint 40%. À cinq projets en parallèle, 75% du temps est absorbé par le passage d’un sujet à l’autre, ce qui laisse 5% de capacité effective par projet.
Ces chiffres concernent des projets entiers, mais le mécanisme s’applique à toute granularité. Un développeur qui alterne entre trois user stories subit le même coût cognitif, proportionnellement. Chaque interruption nécessite de reconstruire le contexte mental: où en étais-je, quelle était la contrainte, quel choix avais-je écarté et pourquoi. Ce temps de rechargement n’apparaît sur aucun tableau de bord, mais il consume une part substantielle de la capacité de l’équipe.
Pourquoi les équipes accumulent du travail en cours
Si le problème est si bien documenté, pourquoi persiste-t-il? Parce que les incitations organisationnelles poussent systématiquement dans la mauvaise direction.
Commencer une tâche donne un signal visible de progrès. Un tableau avec dix cartes en mouvement paraît plus dynamique qu’un tableau avec trois cartes qui avancent méthodiquement vers “terminé”. Les revues de sprint récompensent le volume de travail entamé plus souvent qu’elles ne valorisent le travail achevé, et dire “je suis dessus” à un stakeholder (partie prenante) coûte moins cher à court terme que dire “c’est dans la file, on le prendra quand on aura terminé l’item en cours”.
Il y a aussi un facteur d’évitement. Quand un développeur est bloqué sur une tâche, la tentation est forte de démarrer autre chose plutôt que de traiter le blocage. Le WIP augmente d’une unité, le problème initial reste entier et une nouvelle tâche vient alourdir la charge cognitive collective.
Ce que révèle le WIP sur une équipe
Le WIP (Work In Progress), c’est-à-dire le nombre d’éléments commencés mais pas encore terminés, est un indicateur de santé organisationnelle souvent sous-estimé. Un WIP élevé chronique signale presque toujours un ou plusieurs problèmes structurels: des dépendances externes qui bloquent l’avancement, un manque de compétences croisées qui empêche l’entraide, une difficulté à prioriser qui transforme chaque demande en urgence parallèle.
La loi de Little formalise cette relation. Le temps moyen de traversée d’un système (lead time) est égal au WIP divisé par le débit. Prenons un exemple concret: une équipe a 10 items en cours et termine en moyenne 2 items par jour. Son lead time moyen est de 5 jours par item. Si cette équipe réduit son WIP à 6 items sans changer son débit, le lead time tombe à 3 jours. Chaque item est livré deux jours plus tôt, sans travailler davantage. Ce résultat, démontré mathématiquement par John D.C. Little en 1961, s’applique à toute file d’attente stable, y compris un backlog d’équipe.
La résistance aux limites et ses racines
Proposer de limiter le WIP provoque presque toujours une résistance initiale, et cette résistance est rarement technique.
Limiter le travail en cours oblige à faire des choix explicites de priorité. Quand le WIP est illimité, tout peut être “en cours” simultanément et personne n’a besoin de trancher. Introduire une limite force la question: entre ces deux items, lequel fait-on d’abord? Cette question, en apparence simple, expose les désaccords de priorité que le multitâche permettait de masquer.
Il y a aussi la peur du temps “perdu”. Si un développeur a terminé son item et que la colonne suivante est pleine, il ne peut pas tirer un nouvel élément. Que fait-il? Il aide un collègue à débloquer un item existant, il améliore un test, il documente une décision technique. Ce temps n’est pas perdu: c’est précisément là que se construisent la qualité et la polyvalence de l’équipe. Mais cela demande de renoncer à l’illusion rassurante d’un tableau où chacun a “sa” carte en cours.
Comment mettre en place des limites WIP
L’approche la plus efficace consiste à rendre le problème visible avant de proposer la solution. Mesurer le temps de cycle réel sur deux ou trois sprints, puis poser la question en rétrospective: pourquoi les items passent-ils en moyenne huit jours dans le workflow alors que le travail effectif sur chacun est de deux jours? La réponse pointe invariablement vers le temps d’attente, c’est-à-dire le temps où une tâche est “en cours” mais où personne ne travaille activement dessus.
Le point de départ pragmatique est une limite proche de la taille de l’équipe. Cinq personnes, un WIP de cinq ou six. Les premières semaines seront inconfortables: les blocages, jusque-là noyés dans le bruit du multitâche, deviennent visibles et urgents. C’est l’effet recherché, car une limite WIP ne résout pas les problèmes mais les rend impossibles à ignorer.
En Scrum, la Sprint Retrospective est le moment naturel pour ajuster ces limites sur la base des données observées. L’équipe examine le nombre d’exceptions, le temps de cycle moyen et la fréquence des blocages. Si la limite est systématiquement dépassée, soit elle est trop basse, soit un problème structurel doit être traité. Modifier la limite devrait être la dernière option, pas la première.
Le rôle du management
Les limites WIP ne peuvent pas fonctionner si le management continue d’empiler les demandes. Un sponsor qui insiste pour que “tout soit prioritaire” annule mécaniquement toute politique de limitation. Le rôle du Product Owner ou du chef de projet devient alors celui de bouclier: protéger la capacité de l’équipe en séquençant les demandes plutôt qu’en les parallélisant. Ce repositionnement est souvent le changement le plus difficile à obtenir, mais sans lui les limites WIP restent un exercice théorique.