Episode 6 : WIP Limit

Effective PSK — Episode 6

Par définition, le travail en cours (Work In Progress) est tout le travail commencé mais non terminé, tout en prenant en compte le travail mis en file d’attente pour un processus suivant.

Le travail en cours peut être un obstacle à la réalisation du Flow. Nous en discutions dans l’épisode de la Loi de Little, plus il y a de travail en cours, moins le travail est fluide et plus le travail est lent.

Pratique : Limitation du travail en cours

Au sein de l’équipe Scrum, les membres créent des règles dans leur processus pour limiter le nombre d’éléments dans leur Workflow. On utilise les limites de travail en cours (WIP Limit). Les limites sont obligatoires au sein d’un système de flux tiré. L’objectif est de contrôler explicitement les éléments de travail en cours depuis le moment où ils sont considérés comme “démarrés” jusqu’au moment où ils sont “terminés”.

Notons, qu’en soi le Sprint est une WIP Limit. Il limite le travail à un sous-ensemble sur une courte période.

Les WIP Limits s’appliquent :

• sur les Product Backlog Item (PBI), il concerne le flux de valeur et non les tâches
• sur une colonne, une voie, par personne, par unité de temps (exemple 10 PBIs par semaine), sur le board globale,…

Les règles de limitation sont définies par les personnes travaillant au plus proche du processus. Si on parle du flux du Sprint Backlog alors l’équipe de développement est responsable de la définition, comme de la modification des limites. Si on prend l’ensemble du flux du Backlog (analyse, raffinage,…) alors c’est l’équipe Scrum. Dans ce sens, il favorise l’auto-organisation des membres.

Lors de la définition d’une limite, cette dernière doit introduire, en quelque sorte, une tension pour les membres de l’équipe. L’objectif est que l’équipe sorte de sa zone de confort et qu’elle se dépasse. Le défi serait de canaliser cette tension en cherchant des moyens d’améliorer le processus afin qu’à l’avenir le flux soit meilleur et que la limite d’effacement soit moins douloureuse. Cela pourrait passer, par exemple, par l’amélioration des pratiques d’ingénierie (TDD, CI, CD,…), l’interaction entre les différents acteurs, ou encore la réduction de la taille des lots. C’est dans ce sens que l’optimisation du flux de valeur se manifeste.

La mise en pratique au cours d’un Sprint

Lorsqu’un développeur termine une tâche et que la limite est atteinte, au lieu de démarrer une nouvelle tâche, il aide les autres membres de l’équipe de développement à faire avancer les éléments. La pratique de WIP Limit favorise la collaboration entre les membres de l’équipe et renforce la cohésion de l’équipe.

Il arrive qu’un travail urgent soit identifié et que le Product Owner estime qu’il doit être effectué avec la plus haute priorité. Dans le cas où l’équipe de développement n’a aucune capacité disponible, le sujet pourrait être traité de deux façons :

• Si l’élément peut attendre quelques jours : l’équipe vérifie les travaux en cours et si un membre se libère prochainement, elle attend que ce dernier soit disponible pour prendre l’élément suivant en haute-priorité.
• Si l’élément doit être fait immédiatement : l’équipe décide de passer l’élément en “expedite”. C’est-à-dire le faire en dépassant la limite. L’évènement est marqué en tant qu’exception. Ceci dit, ce cas ne devrait pas arriver et devrait faire l’objet d’une discussion et analyse au cours de la Sprint Retrospective suivante.

La définition des WIP Limit peut être modifiée à tout moment. Il n’existe pas de règles. Cependant, il serait préférable que cela soit fait au cours d’une Sprint Retrospective, tout comme la Definition of Done qui n’est généralement pas modifiée au cours du Sprint pour adapter “tactiquement” la gestion.

Pour conclure cette épisode, la limitation du travail en cours est une technique puissante pour la mise en place d’un système basé sur un flux tiré.

Il apporte de nombreux avantages, comme un rythme soutenable (limite du travail, moins de stress,…), favorise la collaboration entre les membres, réduit le temps de cycle moyen diminuant par la même occasion les cycles de rétroaction (feedback loop).

Points clés :

• L’équipe définit ses WIP Limits
• La responsabilité des limites dépend de la portée
• Au moins une WIP Limit pour un flux tiré
• S’applique aux éléments de travail (PBI) et non les tâches
• S’applique sur une colonne, ligne, personne, …
• Modifiable au cours du Sprint, bien qu’il soit préférable de le faire au cours de la Retrospective