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 au moment où elles ont plus de huit ou neuf personnes. Le travail se fait — les emails sont envoyés, les fonctionnalités sont expédiées, les clients sont gérés — mais personne n'a une idée claire de ce que tout le monde d'autre fait. Les projets s'accumulent. Les choses sont promises puis discrètement oubliées. Vous passez vingt minutes avant chaque réunion pour comprendre où un morceau de travail est réellement. La réponse, généralement, est "quelque part."

C'est le problème que Kanban a été conçu pour résoudre. Non pas le problème de la stratégie, de l'embauche des bonnes personnes, ou de la construction d'une culture — mais le problème opérationnel spécifique et usant de savoir sur quoi votre équipe travaille et ce qui gêne.

C'est un outil étonnamment humble pour quelque chose qui a attiré autant d'attention. Kanban ne prétend pas corriger votre organisation. Cela rend juste le travail visible. Et il s'avère que la visibilité, appliquée de manière cohérente, 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é développé par Toyota à la fin des années 1940 comme un moyen de gérer l'inventaire dans leurs usines de fabrication. L'idée était simple : plutôt que de produire des pièces selon un calendrier fixe, l'usine ne les produirait que si une station en aval signalait qu'elle en avait besoin. Une carte physique — le kanban — remonterait le long de la ligne comme une demande. Rien n'a été fabriqué de manière spéculative. Rien n'a pris du retard inutilement.

L'aperçu que Toyota a eu, et que les équipes logicielles ont emprunté plus tard, est que la plupart des inefficacités dans un système ne viennent pas des gens travaillant trop lentement, mais du mauvais travail étant fait au mauvais moment. Trop de choses commencées à la fois. Des goulots d'étranglement que personne ne remarque jusqu'à ce qu'il soit trop tard. Du travail qui reste terminé à un endroit tandis que l'étape suivante est submergée ailleurs.

Les développeurs de logiciels, particulièrement dans des entreprises comme Microsoft au début des années 2000, ont commencé à adapter ces idées pour le travail de connaissance. Les cartes sont devenues des tâches. Les stations d'usine sont devenues des étapes dans un flux de travail. Et le panneau est devenu un tableau — physiquement d'abord, puis numérique — où n'importe qui dans l'équipe pouvait voir, en un coup d'œil, ce qui était en cours, ce qui attendait, et ce qui était fait.

Ce qu'un tableau Kanban vous montre réellement

Un tableau Kanban basique a trois colonnes : À faire, En cours, Fait. C'est suffisant pour de nombreuses petites équipes et un bon endroit pour commencer. Mais la véritable valeur émerge quand vous commencez à personnaliser ces étapes pour correspondre à la façon dont votre travail coule réellement — pas comment vous souhaitez qu'il coule.

Une équipe de contenu pourrait utiliser : Idée, Brève, En brouillon, En revue, Programmé, Publié. Une équipe logicielle pourrait diviser "En cours" en colonnes séparées pour le développement, l'examen du code et l'assurance qualité. Une équipe de conseil pourrait suivre Découverte, Proposition, Actif, En attente du client, Fermé. Les étapes doivent refléter les vrais transferts et les vrais temps d'attente — des endroits où le travail change de mains, ou où il reste jusqu'à ce que quelque chose d'autre se passe.

Remarquez la carte dans la colonne du milieu — le rapport d'audit d'entrepôt, après huit jours, marqué comme bloqué. Dans un système sans tableau, cette tâche pourrait rester deux autres semaines avant que quelqu'un se rende compte qu'elle ne se déplace pas. Quelqu'un attend une tierce partie. Ou une décision est nécessaire d'un gestionnaire qui ne sait pas qu'il est le goulot. Le tableau rend le blocage visible. C'est la plupart du travail.

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

S'il y a un concept qui sépare les équipes utilisant Kanban correctement des équipes qui ont juste une liste de choses à faire plus jolie, ce sont les limites de travail en cours — les limites WIP en abrégé. L'idée est que chaque colonne a un nombre maximum d'articles qui sont autorisés à être là à la fois. Quand une colonne est pleine, vous ne pouvez pas ajouter plus de travail jusqu'à ce que quelque chose se déplace.

Cela semble contre-intuitif. Être capable de mettre plus de tâches en cours n'est-il pas le moyen que plus se fasse ? Non. Ce qui se passe réellement quand les gens travaillent sur trop de choses simultanément, c'est que tout prend plus de temps. Le changement de contexte est coûteux. Le travail inachevé crée une surcharge de coordination. Et quand dix choses sont "en cours," il est très difficile de dire lesquelles sont réellement en mouvement et lesquelles sont juste bloquées mais non marquées.

Une limite WIP de trois sur votre colonne En cours signifie que lorsque la quatrième chose arrive au bureau de quelqu'un, quelqu'un dans l'équipe doit prendre une décision : quelle tâche existante se termine en premier ? Cela force la priorisation. Cela force la conversation. Et cela tend à produire une réalisation plus rapide des articles individuels, même si le taux de démarrage des nouveaux articles ralentit.

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

Si vous avez passé du temps autour des équipes logicielles ou de la pensée opérationnelle moderne, vous avez probablement rencontré Scrum — le cadre qui organise le travail en sprints fixes de deux semaines, avec des sessions de planification, des rétrospectives, et des rôles définis comme Scrum Master et Product Owner. De nombreuses équipes traitent Scrum et Kanban comme des méthodologies concurrentes et sentent qu'elles doivent choisir. La distinction est en fait plus simple que cela.

De nombreuses équipes — en particulier celles qui ne sont pas des équipes d'ingénierie logicielle pure — trouvent les cérémonies de Scrum lourdes et sa structure de sprint fixe maladroite à appliquer au travail opérationnel continu. Les équipes marketing, les équipes de succès client, les équipes d'opérations, et les fondateurs gérant tout-en-même rarement ont du travail qui s'adapte nettement aux cycles de deux semaines. Le modèle de flux continu de Kanban a tendance à mieux les convenir.

Cela dit, de nombreuses équipes combinent les deux. Elles utilisent des cycles de planification de style sprint pour le développement produit tout en exécutant un tableau Kanban pour le travail opérationnel et d'assistance qui circule indépendamment du sprint dans lequel vous êtes. C'est un hybride parfaitement raisonnable.

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

Un tableau Kanban est plus utile quand vous pouvez le regarder et, sans parler à quelqu'un, répondre rapidement à ces trois questions : Sur quoi l'équipe travaille actuellement ? 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 dans les trente secondes de regarder le tableau, il n'est probablement pas entretenu correctement. Le mode d'échec le plus courant est un tableau où les tâches sont créées mais jamais déplacées — cela devient un cimetière de bonnes intentions plutôt qu'une carte en direct du travail réel. Un tableau qui n'est pas actuel est pire que pas de tableau, car il crée un faux sentiment de visibilité.

La discipline requise pour maintenir un tableau est réelle. Les tâches doivent se déplacer quand le travail se déplace. Les articles bloqués doivent être marqués dès qu'ils s'arrêtent, pas deux semaines plus tard. Les cartes doivent avoir des propriétaires clairs, et les propriétaires doivent mettre à jour leurs cartes. Rien de cela ne nécessite beaucoup de temps — une pratique Kanban bien gérée pourrait prendre cinq à dix minutes par personne par jour — mais cela nécessite de la cohérence. Les équipes qui bénéficient le plus de Kanban sont celles qui traitent le tableau comme la source de vérité, pas comme un exercice d'archivage supplémentaire.

Ce que Kanban ne fait pas

Kanban n'est pas un outil de stratégie. Cela ne vous aidera pas à comprendre sur quoi travailler — seulement vous aider à gérer ce sur quoi vous avez déjà décidé de travailler. Si votre organisation a un problème de priorisation, ou un problème de mandat flou, ou un problème "nous commençons trop de projets avant de terminer les anciens" enraciné dans le comportement du leadership plutôt que le processus, un tableau Kanban révélera ces problèmes mais ne les résoudra pas.

Ce n'est pas non plus un substitut à une bonne gestion. Un tableau ne remplace pas les réunions un-à-un, ou la délégation réfléchie, ou la communication claire sur les raisons pour lesquelles certains travaux comptent. Les équipes adoptent parfois des outils de processus en espérant que le processus fera le travail relationnel et organisationnel qui est réellement le travail du gestionnaire. Cela ne le fera pas.

Ce qu'il fera, c'est réduire l'incertitude ambiante qui ralentit la plupart des équipes. Les questions de "qui travaille sur quoi," "est-ce fait," et "que devrait-je ramasser ensuite" génèrent des quantités énormes de communication de faible valeur dans les organisations qui n'ont pas un système partagé et visible. Kanban élimine la plupart de ce bruit. Et pour les équipes où ce bruit est le problème dominant, la différence est significative.

Comment commencer — sans un atelier de trois jours

Les meilleures implémentations Kanban que j'ai vues ont commencé petit et évoluées. Les pires impliquaient un consultant, une retraite de deux jours, et un tableau magnifiquement conçu que personne n'utiliserait à la semaine trois.

Commencez par votre équipe telle qu'elle est réellement, avec le travail que vous avez réellement. Créez trois colonnes : Arriéré, En cours, Fait. Passez trente minutes avec votre équipe en mettant 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 se déplace, vous déplacez la carte. Ne faites rien d'autre pendant deux semaines.

Après deux semaines, regardez le tableau ensemble. Où les choses s'étaient-elles accumulées ? Qu'est-ce qui est resté en Arriéré que tout le monde a dit être une priorité ? Qu'est-ce qui s'est déplacé plus vite que prévu ? Qu'est-ce qui s'est bloqué et pourquoi ? Utilisez ce que vous observez pour affiner les colonnes et ajouter de la spécificité. Peut-être que "En cours" doit se diviser en "En cours" et "En attente d'externe." Peut-être avez-vous besoin d'une colonne appelée "En revue" parce que cette étape est toujours perdue. Laissez le tableau évoluer en réponse à ce que votre travail réel révèle, pas en réponse à ce qu'un livre de méthodologie dit qu'il devrait ressembler.

Le jeu plus long : 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'utilisent jamais. Le délai — le temps total du moment où une tâche est créée jusqu'à ce qu'elle soit complétée — est le plus important. Si votre délai moyen pour une tâche typique est de douze jours, et que vous voulez que ce soit cinq, vous avez maintenant un nombre auquel travailler et un tableau qui vous montrera où ces sept jours supplémentaires vont.

Le temps de cycle mesure uniquement la période de travail active, excluant le temps qu'une tâche reste en arrière-plan. Le débit mesure le nombre d'articles que votre équipe complète par semaine. Aucune de ces métriques ne nécessite de logiciel spécial si vous êtes discipliné sur la notation du moment où les cartes sont créées et quand elles sont fermées. Et ensemble, elles vous donnent une image beaucoup plus honnête de la capacité de votre équipe que tout processus de planification basé sur l'estimation peut.

La plupart des petites et moyennes équipes n'arrivent jamais ici. Elles utilisent Kanban comme un outil de visibilité — ce qui est précieux en soi — et ne vont pas plus loin. C'est correct. Mais si vous vous trouvez voulant faire des engagements auprès des parties prenantes sur quand quelque chose sera fait, ou voulant comprendre pourquoi un travail prend trois fois plus longtemps que prévu, les métriques sont là quand vous en avez besoin.