Pourquoi Kanban fonctionne — et comment savoir si votre équipe est prête

La plupart des équipes adoptent Kanban parce que quelqu'un a lu un article de blog. La meilleure question est de savoir si les problèmes que Kanban résout sont réellement les problèmes de votre équipe.

Il y a un moment que la plupart des équipes reconnaissent, généralement dès qu'elles dépassent huit ou neuf personnes. Le travail avance — les e-mails partent, les fonctionnalités sortent, les clients sont suivis — mais personne n'a une idée claire de ce que font les autres. Les projets s'accumulent. On promet des choses, puis on les oublie discrètement. Vous passez vingt minutes avant chaque réunion à essayer de comprendre où en est tel dossier. La réponse, en général, c'est « quelque part ».

C'est le problème que Kanban a été conçu pour résoudre. Pas le problème de la stratégie, du recrutement des bonnes personnes ou de la construction d'une culture — mais le problème opérationnel, précis et épuisant, de savoir sur quoi votre équipe travaille et ce qui la freine.

C'est un outil étonnamment modeste pour quelque chose qui a attiré autant d'attention. Kanban ne prétend pas réparer votre organisation. Il rend simplement le travail visible. Et il se trouve que la visibilité, appliquée avec constance, change un nombre remarquable de choses en aval.

D'où Kanban vient réellement

Le mot est japonais — il signifie « panneau » ou « affiche » — et le système a été mis au point par Toyota à la fin des années 1940 pour gérer les stocks dans ses usines. L'idée était simple : plutôt que de produire des pièces selon un calendrier fixe, l'usine ne les fabriquerait que si un poste en aval signalait en avoir besoin. Une carte physique — le kanban — remonterait la chaîne comme une demande. Rien n'était fabriqué par anticipation. Rien ne prenait du retard inutilement.

Ce que Toyota a compris, et que les équipes logicielles ont repris plus tard, c'est que la plupart des inefficacités d'un système ne viennent pas de gens qui travaillent trop lentement, mais d'un mauvais travail fait au mauvais moment. Trop de choses démarrées en même temps. Des goulots d'étranglement que personne ne remarque avant qu'il soit trop tard. Du travail terminé qui attend à un endroit pendant que l'étape suivante est débordée ailleurs.

Les développeurs de logiciels, notamment dans des entreprises comme Microsoft au début des années 2000, ont commencé à adapter ces idées au travail intellectuel. Les cartes sont devenues des tâches. Les postes d'usine sont devenus des étapes d'un flux de travail. Et le panneau est devenu un tableau — physique d'abord, puis numérique — où chacun dans l'équipe pouvait voir, en un coup d'œil, ce qui était en cours, ce qui attendait et ce qui était terminé.

Ce qu'un tableau Kanban vous montre réellement

Un tableau Kanban de base compte trois colonnes : À faire, En cours, Terminé. C'est suffisant pour de nombreuses petites équipes, et un bon point de départ. Mais la vraie valeur apparaît quand vous personnalisez ces étapes pour qu'elles correspondent à la façon dont votre travail circule réellement — et non à la façon dont vous aimeriez qu'il circule.

Une équipe de contenu pourrait utiliser : Idée, Brief, Rédaction, Relecture, Planifié, Publié. Une équipe logicielle pourrait scinder « En cours » en colonnes distinctes pour le développement, la revue de code et l'assurance qualité. Une équipe de conseil pourrait suivre : Cadrage, Proposition, Actif, En attente du client, Clôturé. Les étapes doivent refléter les vraies passations et les vrais temps d'attente — là où le travail change de mains, ou où il reste en suspens jusqu'à ce que quelque chose d'autre se produise.

Remarquez la carte de la colonne du milieu — le rapport d'audit d'entrepôt, bloqué depuis huit jours. Sans tableau, cette tâche pourrait rester ainsi deux semaines de plus avant que quelqu'un s'aperçoive qu'elle n'avance pas. Quelqu'un attend un tiers. Ou il faut une décision d'un responsable qui ignore qu'il est le goulot d'étranglement. Le tableau rend le blocage visible. C'est l'essentiel du travail.

La règle qui le rend fonctionnel : les limites WIP

S'il y a un concept qui distingue les équipes qui utilisent Kanban correctement de celles qui ont simplement une liste de tâches plus jolie, ce sont les limites de travail en cours — les limites WIP, en abrégé. Le principe : chaque colonne a un nombre maximal d'éléments autorisés en même temps. Quand une colonne est pleine, on ne peut plus y ajouter de travail tant que quelque chose n'a pas avancé.

Cela paraît contre-intuitif. Pouvoir lancer plus de tâches en parallèle, n'est-ce pas le moyen d'en faire plus ? Non. Quand les gens travaillent sur trop de choses à la fois, tout prend plus de temps. Le changement de contexte coûte cher. Le travail inachevé crée une charge de coordination. Et quand dix choses sont « en cours », il est très difficile de dire lesquelles avancent vraiment et lesquelles sont simplement bloquées sans être signalées.

Une limite WIP de trois sur votre colonne En cours signifie que, lorsqu'un quatrième élément arrive sur le bureau de quelqu'un, il faut trancher dans l'équipe : quelle tâche en cours se termine en premier ? Cela impose de prioriser. Cela impose d'en discuter. Et cela tend à accélérer l'achèvement de chaque élément, même si le rythme de démarrage des nouveaux ralentit.

Kanban ou Scrum : la question que les équipes posent toujours

Si vous avez fréquenté des équipes logicielles ou les approches opérationnelles modernes, vous avez probablement croisé Scrum — le cadre qui organise le travail en sprints fixes de deux semaines, avec des séances de planification, des rétrospectives et des rôles définis comme Scrum Master et Product Owner. Beaucoup d'équipes voient Scrum et Kanban comme des méthodes concurrentes et pensent devoir choisir. La différence est en réalité plus simple que cela.

Beaucoup d'équipes — en particulier celles qui ne sont pas de pures équipes d'ingénierie logicielle — trouvent les cérémonies de Scrum lourdes et sa structure de sprints fixes malcommode pour du travail opérationnel continu. Les équipes marketing, succès client ou opérations, et les fondateurs qui font tout à la fois, ont rarement un travail qui rentre proprement dans des cycles de deux semaines. Le modèle de flux continu de Kanban leur convient généralement mieux.

Cela dit, beaucoup d'équipes combinent les deux. Elles utilisent des cycles de planification façon sprint pour le développement produit, tout en gérant avec un tableau Kanban le travail opérationnel et le support, qui circule indépendamment du sprint en cours. C'est un hybride tout à fait raisonnable.

Les trois questions auxquelles votre tableau devrait répondre en trente secondes

Un tableau Kanban est le plus utile quand vous pouvez le regarder et, sans parler à personne, répondre rapidement à ces trois questions : sur quoi l'équipe travaille-t-elle en ce moment ? Où le travail s'accumule-t-il ? Y a-t-il quelque chose qui devrait être fait et qui n'a pas été commencé ?

Si vous ne pouvez pas répondre aux trois questions en trente secondes en regardant le tableau, c'est probablement qu'il n'est pas bien tenu. Le défaut le plus courant est un tableau où les tâches sont créées mais jamais déplacées — il devient un cimetière de bonnes intentions plutôt qu'une carte vivante du travail réel. Un tableau qui n'est pas à jour est pire que pas de tableau, car il donne un faux sentiment de visibilité.

La discipline nécessaire pour tenir un tableau est réelle. Les tâches doivent bouger quand le travail bouge. Les éléments bloqués doivent être signalés dès qu'ils s'arrêtent, pas deux semaines plus tard. Les cartes doivent avoir des responsables clairs, et ceux-ci doivent mettre à jour leurs cartes. Rien de tout cela ne demande beaucoup de temps — une pratique Kanban bien rodée peut prendre cinq à dix minutes par personne et par jour — mais cela demande de la régularité. Les équipes qui tirent le plus de Kanban sont celles qui traitent le tableau comme la source de vérité, et non comme une corvée administrative de plus.

Ce que Kanban ne fait pas

Kanban n'est pas un outil de stratégie. Il ne vous aidera pas à déterminer sur quoi travailler — seulement à gérer ce que vous avez déjà décidé de faire. Si votre organisation a un problème de priorisation, un problème de mandat flou, ou un problème du type « nous lançons trop de projets avant d'avoir fini les anciens » qui tient au comportement de la direction plutôt qu'au processus, un tableau Kanban fera apparaître ces problèmes mais ne les résoudra pas.

Ce n'est pas non plus un substitut à un bon management. Un tableau ne remplace ni les entretiens individuels, ni une délégation réfléchie, ni une communication claire sur les raisons pour lesquelles certains travaux comptent. Les équipes adoptent parfois des outils de process en espérant que le process fera le travail relationnel et organisationnel qui relève en réalité du manager. Ce ne sera pas le cas.

Ce qu'il fera, en revanche, c'est réduire l'incertitude ambiante qui ralentit la plupart des équipes. Les questions du type « qui travaille sur quoi », « est-ce terminé » et « que dois-je prendre ensuite » génèrent une énorme quantité de communication à faible valeur dans les organisations qui n'ont pas de système partagé et visible. Kanban élimine l'essentiel de ce bruit. Et pour les équipes dont ce bruit est le problème dominant, la différence est significative.

Comment commencer — sans un atelier de trois jours

Les meilleures mises en place de Kanban que j'ai vues ont commencé petit et ont évolué. Les pires impliquaient un consultant, un séminaire de deux jours et un tableau magnifiquement conçu que plus personne n'utilisait à la troisième semaine.

Partez de votre équipe telle qu'elle est, avec le travail que vous avez réellement. Créez trois colonnes : Backlog, En cours, Terminé. Passez trente minutes avec votre équipe à mettre chaque élément de travail actuel sur une carte. Acceptez une règle : quand vous commencez quelque chose, cela va sur le tableau. Quand cela avance, vous déplacez la carte. Ne faites rien d'autre pendant deux semaines.

Après deux semaines, examinez le tableau ensemble. Où les choses se sont-elles accumulées ? Qu'est-ce qui est resté dans le backlog alors que tout le monde disait que c'était une priorité ? Qu'est-ce qui a avancé plus vite que prévu ? Qu'est-ce qui s'est bloqué, et pourquoi ? Servez-vous de ce que vous observez pour affiner les colonnes et gagner en précision. Peut-être que « En cours » doit se scinder en « En cours » et « En attente d'un tiers ». Peut-être avez-vous besoin d'une colonne « En revue » parce que cette étape se perd toujours. Laissez le tableau évoluer en fonction de ce que révèle votre travail réel, pas de ce qu'un livre de méthodologie dit qu'il devrait être.

Voir plus loin : les métriques de flux

Une fois qu'un système Kanban fonctionne, il génère des données que la plupart des équipes n'exploitent jamais. Le lead time — le temps total entre la création d'une tâche et son achèvement — est le plus important. Si votre lead time moyen pour une tâche type est de douze jours et que vous voulez le ramener à cinq, vous avez désormais un chiffre sur lequel travailler et un tableau qui vous montrera où passent ces sept jours en trop.

Le cycle time ne mesure que la période de travail actif, hors temps d'attente d'une tâche. Le débit mesure le nombre d'éléments que votre équipe termine par semaine. Aucune de ces métriques ne nécessite de logiciel particulier si vous notez rigoureusement la date de création et de clôture des cartes. Et ensemble, elles donnent une image bien plus honnête de la capacité de votre équipe que n'importe quel processus de planification fondé sur l'estimation.

La plupart des petites et moyennes équipes n'y arrivent jamais. Elles utilisent Kanban comme outil de visibilité — ce qui est précieux en soi — et ne vont pas plus loin. C'est très bien. Mais si vous voulez vous engager auprès des parties prenantes sur la date d'achèvement de quelque chose, ou comprendre pourquoi un travail prend trois fois plus de temps que prévu, les métriques sont là quand vous en avez besoin.