[LeanKanban France 2013] Help ! Kanban maxed out ! What can I do now ?

Cette session, présentée par Steve Tendon (un excellent orateur, soit dit en passant), et donnée lors de la première journée du Lean Kanban France 2013, se proposait de répondre à la problématique suivante : mon équipe travaille en Kanban depuis un certain temps. Au début les améliorations de processus étaient nombreuses, peut-être même faciles à détecter, mais depuis quelque temps, nous ne progressons plus. Comment continuer à évoluer ? Où trouver de nouvelles pistes d’améliorations ?

Tout d’abord, petit rappel salutaire : la règle 6 du Kanban stipule qu’il faut améliorer nos processus collaborativement et évoluer de manière expérimentale, en utilisant des méthodes scientifiques. Utiliser une méthode scientifique, dans ce contexte, signifie se servir de métriques adaptées pour décider où placer nos changements de processus et contrôler leur pertinence une fois qu’ils ont été adoptés, en se laissant la possibilité de revenir en arrière si, au final, le changement s’avère non pertinent. Un exemple de méthode scientifique est le PDCA, popularisé par le docteur Demming.

Certes, nous devons nous améliorer, mais posons-nous maintenant la question de savoir ce que l’on cherche à faire exactement en améliorant nos processus. En Kanban, on peut trouver deux buts principaux à ce type d’action :

• Rendre notre système plus fluide ;
• Améliorer notre débit de sorti.

La théorie des contraintes

Une fois toutes ces données posées, Steve nous propose d’utiliser la théorie des contraintes développée par Eliyahu M. Goldratt dans son livre « Le But ». Ecrit sous la forme d’un roman, ce livre nous fait suivre les aventures d’un directeur d’usine ayant de nombreux problèmes tant dans sa vie professionnelle que personnelle et qui arrive à tous les résoudre grâce à l’application de la théorie des contraintes. Pour résumer, cette théorie part du principe que chaque système a une contrainte, c’est-à-dire une étape plus lente, moins efficace que les autres, ce qui est tout à fait normal. Il faut donc travailler pour essayer de lever cette contrainte, et ce en 5 étapes :

• Identifier la contrainte ;
• Exploiter la contrainte ;
• Subordonner tout le système à la contrainte ;
• Lever la contrainte ;
• Recommencer, c’est-à-dire trouver la nouvelle contrainte qui invariablement apparaîtra dans notre système ;

Dans le roman, pour illustrer ces 5 étapes, notre héros se retrouve à accompagner son fils et sa troupe de scouts dans une randonnée. Son objectif, arriver le plus vite possible à destination, sans perdre personne en route. Malheureusement, dans la troupe se trouve un scout que l’on qualifiera de bien en chair et qui porte, de plus, un très gros sac. Le groupe marchant en file indienne, sa présence au milieu de la file va générer des perturbations. Nos 5 étapes deviennent donc :

• Identifier la contrainte : il s’agit de notre scout que l’on nommera Herbie ;
• Exploiter la contrainte : on lui demande de se dépêcher. Dans le cas présent, ce n’est pas très efficace. On passe donc à l’étape suivante ;
• Subordonner le système à la contrainte : on fait marcher Herbie devant le groupe. Certes, l’ensemble du système est ralenti (on diminue donc notre débit), mais au moins, tout le monde reste groupé et avance au même rythme (on stabilise donc notre flux) ;
• Lever la contrainte : on va alléger Herbie et répartir ce qu’il transporte dans son sac dans les sacs de ses camarades. De fait, le débit va commencer à augmenter ;
• Enfin, on recommence : Herbie n’est peut-être plus le scout le plus lent de la bande, il nous faut donc identifier notre nouvelle contrainte.

Un point très important dans cette histoire, outre ces 5 étapes, est le côté collectif de l’action : tout le monde participe, tout le monde se partage la charge et tout le monde est derrière la contrainte. Cette vision globale, cette opération collective, se retrouve tout à fait dans la philosophie Kanban.

Kanban sous contrainte

Et dans Kanban justement, comment mettre tout ça en place ? Tout simplement en constatant que notre ami Herbie, notre contrainte donc, est un goulot d’étranglement. Nous allons donc pouvoir travailler dessus.

En s’appuyant sur la loi de Little, qui traite de la capacité d’un système en flux, Herbie représente la capacité maximale de notre système. En d’autres termes, le débit total ne pourra jamais être plus grand que le débit de la contrainte. Ainsi, les autres étapes de notre flux (ou de notre chaîne de valeur) travaillent en sous capacité. Si un problème arrive sur une de ces étapes, ce n’est pas trop grave, car on pourra récupérer le retard avec notre excès de capacité. Par contre, si un problème arrive à la contrainte, c’est l’ensemble du système qui va en pâtir. Ainsi, faire des améliorations sur des étapes du flux, qui ne sont pas la contrainte, permet juste d’augmenter nos possibilités de recouvrement d’erreur. C’est seulement en améliorant notre contrainte que l’on augmentera le débit du système.

Kanban offre de nombreux outils pour détecter la contrainte de notre système : la visualisation sur un tableau tout d’abord. L’utilisation des WIP limits ensuite. Ainsi, en règle générale, les colonnes précédant la contrainte sont remplies, en revanche, les suivantes sont vides ou du moins leur limite n’est jamais atteinte.

Attention toutefois, Steve nous rappelle que ces WIP limits peuvent être des concepts difficiles à manier, il faut être sûr de ces limites, sinon on risque de trouver des faux positifs, de masquer notre contrainte et de se retrouver à optimiser des étapes de notre flux qui n’en ont pas besoin (cf. précédemment).

Pour être certain d’avoir trouvé la vraie contrainte, Steve nous propose de regarder le temps de cycle moyen par colonne, la contrainte se situant généralement là où ce temps de moyen est le plus élevé. C’est aussi en observant ces temps moyens que l’on saura que l’étape 5 est atteinte, c’est-à-dire que la contrainte sur laquelle on a travaillé n’en est plus une, qu’elle s’est déplacée et qu’on peut repartir dans un nouveau cycle d’amélioration.

Comme on l’a dit précédemment, il est très important que la contrainte soit toujours utilisée à son maximum, car quand elle ralentit, l’ensemble du système ralentit. Pour éviter au maximum ce défaut, Steve nous propose de positionner un buffer devant la contrainte. Idéalement, ce buffer est toujours plein. S’il commence à se vider, c’est qu’un problème est en en train d’apparaître dans les phases amonts de notre système : il est temps d’investiguer. Si ce buffer est totalement vide, il devient urgent d’agir ! Ce système nous aidera donc à anticiper les problèmes de sous-alimentation de notre contrainte.

Conclusion

Faute de temps, nous n’avons fait que survoler la deuxième partie de la conférence, qui proposait l’utilisation de buffer associé aux développements de « Minimum Marketable Release ». Ce point n’ayant été que trop peu développé, à mon grand regret, je ne pourrais malheureusement pas en dire beaucoup plus. Nous avons de même survolé la notion de « Reason Tracking » : à chaque fois qu’un problème apparait, on le note et on compte ensuite l’occurrence de chaque type de problème, ce qui peut nous donner de sérieuses pistes d’amélioration.

Néanmoins, le livre de Steve Tendon, « Tame the Flow », développe l’ensemble de ces théories. Ce livre sera très prochainement disponible en français, il ne restera plus aucune raison de ne pas le lire !

Pour aller plus loin

Le PDCA : https://fr.wikipedia.org/wiki/Roue_de_Deming

La loi de Little : https://fr.wikipedia.org/wiki/Loi_de_little