Kanban
Visualisez, limitez, fluidifiez. La méthode Kanban transforme votre flux de travail en pipeline prévisible, du Toyota des années 40 à votre board produit.
Description
La méthode Kanban est un système de gestion visuelle du travail qui utilise des tableaux et des cartes pour représenter les tâches, limite le travail en cours (WIP) et optimise le flux de livraison par l'amélioration continue. Créée par Taiichi Ohno chez Toyota à la fin des années 1940, puis adaptée au développement logiciel par David J. Anderson chez Microsoft en 2004, sa finalité est de rendre visible l'invisible : les goulots d'étranglement, la surcharge et le gaspillage qui ralentissent vos livraisons. Votre équipe travaille sur douze sujets en parallèle, termine peu de choses et livre encore moins. Tout le monde est occupé, personne n'avance. C'est le paradoxe que le Kanban résout avec un principe contre-intuitif : produire plus vite en faisant moins de choses à la fois. Comme un restaurant qui refuse de prendre vingt commandes simultanées parce que la cuisine ne peut en traiter que huit correctement, le tableau Kanban rend visible la capacité réelle de l'équipe et force à respecter ses limites. Le mécanisme central est le WIP limit (limite de travail en cours), qui plafonne le nombre de tâches autorisées dans chaque colonne. Quand une colonne est pleine, personne n'y ajoute de travail tant qu'un élément n'en sort pas. Ce simple mécanisme, formalisé par la Loi de Little (temps de cycle = travail en cours divisé par le débit), démontre mathématiquement que réduire le WIP réduit le temps de cycle. David J. Anderson a codifié ces principes dans son livre Kanban: Successful Evolutionary Change for Your Technology Business (2010), posant les bases du Kanban agile tel qu'il est pratiqué aujourd'hui. Contrairement à Scrum qui impose des sprints, des rôles et des cérémonies, le système Kanban s'adapte à vos processus existants sans révolution organisationnelle. Vous commencez où vous êtes, vous visualisez ce que vous faites, et vous améliorez progressivement.
Objectifs
- Prioriser le travail
- Structurer le développement
- Améliorer la collaboration d'équipe
Utilisé par
- -Toyota (créateur du système Kanban original dans les années 1940, intégré au Toyota Production System de Taiichi Ohno)
- -Microsoft (première application du Kanban au développement logiciel par David J. Anderson en 2004)
- -Spotify (utilise Kanban dans ses squads pour gérer le flux de livraison en continu)
Avantages
- Démarrage sans rupture. Kanban s'applique à vos processus existants sans réorganisation, contrairement à Scrum qui exige des sprints et des rôles définis.
- Prévisibilité mesurable. Le cycle time et le throughput remplacent les estimations subjectives par des données. Chez Vanguard, les équipes ont multiplié leur débit par 4 après adoption du Kanban.
- Réduction des blocages. Les WIP limits forcent l'équipe à finir avant de commencer, éliminant le multitâche improductif.
- Flexibilité totale. Pas de sprints rigides. Les priorités changent ? Vous réorganisez le backlog sans attendre la fin d'un cycle.
Limites
- Pas de cadence de planification intégrée. Sans sprints, la planification long terme repose sur votre discipline. Si vous avez besoin de cadence, combinez Kanban avec des revues périodiques.
- Risque de complaisance. Sans engagement sur des objectifs de sprint, l'équipe peut ralentir sans s'en rendre compte. Surveillez le throughput comme indicateur d'alerte.
- Moins structurant pour les équipes junior. Scrum fournit un cadre plus directif (rôles, cérémonies, sprints). Kanban demande de l'autonomie et de la maturité.
- Ne gère pas les dépendances inter-équipes. Si vos tâches dépendent d'autres équipes, le tableau Kanban seul ne suffit pas. Regardez du côté de SAFe ou des Program Boards.
Comment appliquer Kanban
- 1
Cartographier votre flux de travail actuel
Dessinez les étapes réelles par lesquelles passe une tâche, de l'idée à la livraison. Ne créez pas un processus idéal, documentez ce qui existe. Exemples courants : Backlog, À faire, En cours, En review, Terminé. Ajoutez des colonnes intermédiaires si votre flux l'exige (Design, Dev, QA). Output : un tableau Kanban reflétant votre réalité opérationnelle (Trello, Jira, Linear ou tableau physique).
- 2
Rendre tout le travail visible sur le tableau
Chaque tâche en cours doit avoir une carte sur le tableau. Si une tâche existe mais n'a pas de carte, elle est invisible et donc ingérable. Incluez les demandes ad hoc, les bugs, la dette technique. Le but est de voir l'intégralité de la charge. Output : un tableau où 100% du travail actif est représenté.
- 3
Définir les limites WIP par colonne
C'est l'étape qui change tout. Fixez un nombre maximum de tâches par colonne. Règle de départ : nombre de personnes dans l'équipe divisé par 2, arrondi au supérieur. Exemple : équipe de 6 personnes, WIP limit = 3 en colonne "En cours". Si la colonne est pleine, personne n'ajoute de tâche. On aide d'abord à finir ce qui est commencé. Output : WIP limits affichés sur chaque colonne du tableau.
- 4
Instaurer le système de tirage (pull system)
Les membres de l'équipe ne reçoivent plus de tâches poussées par un manager. Ils tirent la prochaine tâche prioritaire quand ils ont de la capacité disponible. Cela responsabilise chaque contributeur et élimine la micro-gestion. Règle simple : quand vous terminez une tâche, tirez la suivante de la colonne précédente. Output : une équipe qui s'auto-organise autour du flux.
- 5
Mesurer le temps de cycle et le débit
Commencez à tracker deux métriques : le cycle time (combien de temps une tâche passe de "En cours" à "Terminé") et le throughput (combien de tâches terminées par semaine). Ces données remplacent les estimations au doigt mouillé par des prévisions fiables. La Loi de Little vous donne la relation mathématique entre WIP, cycle time et débit. Output : un dashboard avec cycle time moyen et throughput hebdomadaire.
- 6
Identifier les goulots d'étranglement
Regardez votre tableau : où les cartes s'accumulent, il y a un goulet. Si 8 cartes stagnent en "Code Review" et 2 en "Dev", le problème n'est pas la vélocité des développeurs mais la capacité de review. Résolvez le goulet avant d'accélérer les autres étapes. Output : identification des colonnes bloquantes et actions correctives.
- 7
Organiser un standup focalisé sur le flux
Remplacez le standup classique ("hier j'ai fait, aujourd'hui je fais") par un standup flux : parcourez le tableau de droite à gauche. Commencez par ce qui est presque terminé, pas par ce qui commence. Question centrale : "Qu'est-ce qui bloque l'avancement des cartes ?" Output : un standup de 10-15 minutes orienté déblocage.
- 8
Améliorer en continu (kaizen)
Tous les 2-4 semaines, analysez vos métriques en équipe. Le cycle time augmente ? Cherchez pourquoi. Le throughput baisse ? Identifiez la cause. Ajustez les WIP limits si nécessaire, ajoutez ou supprimez des colonnes, affinez les critères de passage d'une colonne à l'autre. Le Kanban n'a pas de "fin", il s'améliore en permanence. Output : un plan d'amélioration continue avec 1-2 ajustements par cycle.