Quand le flux est suffisant

Quand le flux est suffisant, c’est à dire lorsque les limites Kanban n’apportent finalement rien de plus à la mise en place d’un tableau kanban. Cet article m’a été inspiré d’une discussion que j’ai eu récemment et de mon post sur Kanban contre le flux continu. Vous avez peut être déjà mis en place un tableau kanban, et vous vous demandez vraiment si les limites sont vraiment utiles ? Vous avez essayé et ça ne vous a rien apporté ? Alors vous êtes sûrement dans le contexte que je vais décrire ici. Et dans ce cas, les limites Kanban sont effectivement peu utiles, car le problème est ailleurs et voici pourquoi :

Un peu de définition avant de commencer

Ceux qui connaissent un peu Kanban peuvent zapper les définitions.

Et d’abord un point vocabulaire

Un tableau kanban sans limite n’est pas un tableau kanban. C’est la représentation visuelle ou numérique d’un système kanban, c’est à dire d’un processus en flux tiré. Le flux tiré est normalement mis en place en limitant le nombre maximum de tâches en cours. Parler de tableau Kanban sans utiliser de limite est un abus de langage souvent utilisé pour parler d’un tableau avec des cartes dessus. Il faudrait alors simplement parler de management visuel.

Flux versus flux tiré

On parle d’approche en flux lorsque le travail, d’un processus de réalisation, de recrutement, de conception, …, entre et sort plutôt au fil de l’eau et que son débit est suffisant (nombre de tâches qui sort par jour ou par semaine). Ce flux peut être poussé ou tiré.

Quand le flux est suffisant

La question à laquelle cet article répond est : Et si les limites, c’était du #bullshit (se demanderaient bien certains) ?

Je vais reformuler la question pour rester constructif :

Y a-t-il des contextes où une approche simple en flux est suffisant, finalement ?

Je discutais donc avec quelqu’un ayant mis en place du déploiement continu dans sa DSI, du devops à fond, et j’étais un peu étonné qu’un système Kanban ne soit pas présent, les deux vont de pair normalement. Un tableau type kanban est pourtant bien en place, mais sans limites. Ils n’en ont pas ressenti le besoin.

La raison est assez simple : le tableau représente le travail de l’équipe de réalisation. Et le métier, les Product owners, alimentent difficilement le travail de l’équipe. Dès qu’une fonctionnalité entre dans le tableau, elle est aussitôt prise par l’équipe et avance bien.

Les systèmes kanban goutte à goutte

Ce que l’on vient de décrire est assez symptomatique de la présence d’un goulet d’étranglement. Ici c’est le métier (en tout cas quelque part dans le processus de mûrissement du besoin, imaginons que ce soit le Product Owner). L’équipe de réalisation se place juste après le goulet. Le travail sortant du goulet se fait au goutte à goutte. Dans le schéma suivant, nous avons représenté l’effet d’un goulot d’étranglement se situant au niveau sur les tests :

Personnellement, j’appelle cela des systèmes kanban goutte à goutte, car il n’y a pas vraiment de flux en place. Dès qu’une goutte (une carte kanban) rentre dans le système, elle est prise en compte tout de suite et avance, quelques fois en pièce à pièce.

Exemple : une équipe Scrum avec un product owner débordé, une équipe support avec peu de tickets d’incidents …

Limites hautes kanban

Le problème pour ce type d’équipe n’est pas de devoir gérer trop de travail en même temps, mais d’en avoir suffisamment. Il est donc clair que les limites hautes kanban ne servent pas. Ces limites sont beaucoup plus utiles en amont du goulet d’étranglement, pour mieux réguler son travail. Pour notre goulet de Product Owner, il faut plutôt réguler le processus de mûrissement entre les business owners et lui par exemple.

Limites basses kanban

A l’inverse ce sont les limites basses kanban qui vont devenir indispensables. Car elles permettent de mettre en place des seuils minimum pour prévenir le goulet que l’équipe va bientôt manquer du travail, et donc de l’aider à se focaliser pour sortir les prochaines tâches à réaliser. Ces limites sont plus des gardes fous pour ne pas tomber en manque de travail (et oui ça arrive dans certaines organisations).

Alors Kanban ou flux ?

Nous venons de voir que le flux peut être suffisant pour une équipe. Mais c’est le signe que l’on ne regarde qu’une partie du processus. Et qu’il y a probablement un goulet d’étranglement ailleurs, donc un problème à régler, chouette ! Il faut alors regarder le processus de façon plus globale pour optimiser l’ensemble. Et alors l’intérêt des limites hautes kanban apparaître rapidement. Le Kanban va devenir intéressant en considérant le processus de façon plus large.

Donc ce n’est pas grave si vous pensez que le flux est suffisant pour vous. Par contre, assurez-vous que ce ne soit pas le symptôme d’un problème en dehors de votre périmètre.