J'ai un peu tout entendu sur les limites depuis que j'utilise Kanban avec des phrases choc du style : "Si tu n'as pas de limites sur toutes tes colonnes, c'est que tu ne fais pas du Kanban". Et bien je peux maintenant le dire, cette phrase c'est juste .... inexact. Je vais vous expliquer pourquoi, mais surtout comment faire pour limiter le travail en cours.

Un peu de théorie

Et donc à la base il y a la méthode Kanban pour l'IT. David Anderson parle des 5 propriétés coeur de Kanban à savoir visualisation du workflow, limitation du travail en cours, gestion du flux, rendre les règles explicites et s'améliorer collaborativement. Dans cet article, je me concentre sur la limitation du travail en cours dont le but est de maximiser le débit du système (à savoir l'équipe). C'est le même principe de flux que pour une rivière ou un canal. Quand je regarde la rivière couler, je peux voir des tourbillons et des mouvements. Je suis impressionné et je peux me dire "Ça dépote". Voir un canal, c'est l'effet inverse. Je vois de l'eau qui coule de manière régulière, sans un remous, sans rien qui bouge, en résumé c'est pas très funky. Et là je mets la main dans l'eau et je me dis "Ah oui quand même, il y a beaucoup plus de débit que ce que je pensais". C'est assez contre intuitif à première vue, mais vous allez bien augmenter le débit global en diminuant le travail en cours.

Qu'est ce qu'une limite ?

La limite du travail en cours, c'est le débit au delà duquel je génère des perturbations qui in fine vont faire diminuer ma productivité. Ne cherchez pas de formule magique pour déterminer la limite style "2 fois le nombre de personnes moins 1" car elle n'existe pas. Elle est empirique et dépend du contexte. Il va falloir la tailler, ce qui prendra du temps et donc mettre des limites sur toutes les colonnes n'est pas forcément une super idée. Dès que vous changez la composition du système, vous devez retailler vos limites. Exemple : Si vous ajoutez une personne à une équipe, vous enlevez une personne, vous faites un roulement, ... vous devez en théorie retailler vos limites. Dans le cas d'une équipe volatile, cela peut coûter cher de retailler souvent les limites. Autre point important, en fonction du système, je peux avoir une ou plusieurs limites.

Alerte

Une limite c'est un indicateur qui vous montre que vous avez une perturbation. C'est très important dans le monde du développement logiciel car les stocks sont invisibles. Vous savez rarement le nombre de lignes de code "ouvertes". La limite vous aide à prendre des décisions pour rester en mode laminaire. S'il ne se passe rien quand vous tapez une limite, autant ne pas perdre de temps à lire la suite.

Proto Kanban

Il s'agit d'un système avec limites uniquement sur les colonnes "En cours" et aucune sur les files d'attente. Je passe vite sur cette façon de faire car c'est très inefficace. Ça améliore peut être un peu le flux, mais vous cachez les problèmes sous le tapis. Attention aussi à la tentation de ne pas compter les demandes "bloquées pour raison externe" dans les limites, vous reportez le problème sur les autres et ne rendez pas visible vos problèmes. Et quand tout se débloque d'un coup, c'est le drame.

Système localement saturé

Un système est dit localement saturé quand les perturbations sont constatées toujours au même endroit à l'intérieur du système. Si je reste dans la métaphore fluviale, la Sèvre déborde au parc du Loiry en cas de fortes précipitations. Sur des développements informatiques, j'ai fréquemment vu un empilement de demandes dans la colonne "Test". Si je suis la théorie des contraintes, je vais asservir le système sur la contrainte pour faire que le travail soit le plus fluide à ce niveau. C'est le gouleau qui dicte la vitesse du système. En termes de limites, je vais les mettre sur la colonne qui bloque et/ou sur la colonne juste avant.

Système globalement saturé

Je commence par les symptomes pour expliquer. Dans ce cas, les perturbations apparaissent à un endroit, puis un autre, reviennent au début et puis plus loin. Le système n'est pas saturé à cause d'un goulet d'étranglement, mais parce qu'il y a trop de demandes dans le système. Vous essayez d'avaler une bouchée trop grosse. Pour revenir à un système efficace, il faut tout d'abord fermer le robinet pour laisser le système revenir à un état stable. Ensuite, je peux mettre la limite au niveau du système global. Il y a deux variantes sur ce sujet :

- Le clapet : Tous les x semaines, je remets des demandes dans le système jusqu'à atteinte de la limite globale et ensuite je laisse descendre le niveau. C'est une façon de faire type cadence assez proche de ce qui se fait en Scrum. Je ne cherche par contre pas à avoir un système vide en fin de cycle.

- Le fifo alias "First in, first out" : J'attends qu'une demande sorte avant de prendre la prochaine. Je prends la première demande dans une liste ordonnée par un "product manager". J'ai toujours le même nombre de demandes dans le système.

Etapes du process ou profils

Quand j'ai des profils plutôt polyvalents de type T-Shape, je vois plus apparaitre des phénomènes de système globalement saturé. Dans le cas de spécialistes, il s'agit plus de système localement saturés. C'est une aide pour identifier les limites les plus adaptées pour vous. Ensuite, je vais me poser la question d'où mettre des limites. Je vois souvent les colonnes doublées avec "En cours"/"Fait". Je peux mettre une limite sur le bloc des 2 et dans ce cas je mets une limite sur l'étape du process. Je fais cela quand mon problème concerne de la coordination de l'équipe sur l'étape du process. Je peux mettre une limite sur le bloc "En cours" d'une étape et "Fait" de l'étape précédente. Je fais cela quand je veux limiter le travail en cours sur une typologie de personnes pour que le travail soit fluide à son niveau. C'est l'exemple des testeurs qui sont parfois sous l'eau. Je limite le nombre de demandes sur lesquelles ils travaillent et sur leur file d'attente. Le choix dépend pour beaucoup de la polyvalence des ressources.

Le digest

A l'arrivée, voilà ce que cela donne :

- La limitation du travail en cours vise à maximiser le débit en limitant les perturbations.

- Les limites sont empiriques et dépendent du contexte.

- Elles sont un signal d'alerte pour rendre visible les problèmes. S'il ne se passe rien ensuite, elles sont inutiles.

- Vous pouvez mettre des limites sur une colonne, un bloc de colonnes, le système complet,.... Elles vous aide à comprendre là où cela fait mal.