La Méthode Kanban IT (Partie 2) – De la théorie à la mise en oeuvre

Dans la première partie de cette série, nous avons vu ce qu’est la méthode Kanban IT, ses principes fondamentaux, ses valeurs et ses pratiques.

Mais comment passer de la théorie à la pratique ? Comment déployer Kanban au sein d’une équipe ou d’une entreprise ? Quelles sont les étapes de mise en oeuvre ?

Dans cette seconde partie, nous allons explorer les étapes clés de la mise en œuvre d’un Système Kanban IT, en se basant sur le modèle de déploiement proposé par Laurent Morisseau, dans son ouvrage « Kanban pour l’IT« .

🚀 Prêt à transformer la gestion de votre travail avec Kanban ? Suivez le guide !

Portée et Objectifs

1 – Identifier la portée de votre Système Kanban

Avant de mettre en place un Système Kanban IT il est primordial d’identifier les étapes sur lesquelles l’équipe interviendra et aura la main pour gérer, mesurer et améliorer le flux.

Imaginons un constructeur automobile (original, non ? ;)). Il existe de nombreuses étapes et acteurs entre le moment ou vous entrez chez le concessionnaire et celui ou vous recevez votre véhicule :

  • Concessionnaire
  • Usine de fabrication des véhicules
  • Transporteur
  • Financeur
  • SAV
  • …

Chacun de ces acteurs possède son propre Système Kanban, sur lequel chaque équipe a la main et est autonome.

Attention, identifier la portée de votre Système Kanban ne signifie revoir toute l’organisation (comme l’indique le premier principe, vous devez « Commencez la ou vous êtes »), simplement de rendre visible les étapes sur lesquelles l’équipe intervient.

2 – Identifier les interfaces d’entrée et de sortie de votre Système

Il est nécessaire que l’équipe définisse les règles permettant à une demande d’entrée dans son Système. C’est ce que l’on peut nommer une Definition of Ready (DoR), souvent décriée par les gourous du cadre Scrum ne comprenant pas son importance de la considérer comme un cadre collaboratif qui renforce la capacité de l’équipe à délivrer de la valeur.

Restons sur notre constructeur Automobile. Mettez vous dans la peau de l’usine de fabrication n’ayant aucune règle d’entrée et recevant une demande décrivant le véhicule à fabriquer mais ayant omis d’indiquer la couleur. Pensez vous que le client sera ravi de recevoir un véhicule de couleur jaune (je n’ai rien contre le jaune) alors qu’il voulait une voiture noire ?

Tout comme l’interface d’entrée, votre Système Kanban doit également posséder une interface de sortie, décrivant l’ensemble des règles permettant à votre demande de sortir de votre Système Kanban et de passer au processus suivant, en respectant les règles de contrôle qualité. C’est ce que l’on peut nommer la Definition of Done (DoD).

3 – Identifier les douleurs et les objectifs

La mise en place d’un Système Kanban n’a pas pour but de suivre un effet de mode, mais bien de mettre en place une boucle d’amélioration continue et rendre le flux de l’équipe performante.

Pour cela il est nécessaire que l’équipe fasse son introspection, afin d’identifier les problématiques, obstacles ou douleurs qu’elle rencontre, ainsi que ses objectifs d’amélioration.

Nature de la demande

Elements & Flux de Travail

1 – Identifier les éléments de travail

L’étape suivante va porter sur la définition des éléments de travail qui seront suivis dans le Système Kanban.

Pour un Système Kanban, dont l’objectif est la réalisation d’un nouveau produit, les types d’éléments de travail pourraient être :

  • Pour les fonctionnalités Métier  => User Story;
  • Pour les activités techniques transverses => Technical Story (et oui. ça existe !);
  • Pour les corrections d’anomalies => Anomalie ;
  • Pour les adhérences avec des équipes externes au projet => Adhérence ;

Sur un niveau de granularité plus important, les types d’éléments porteront sur :

  • Un ensemble de fonctionnalité minimum et suffisante à la livraison d’une première version du produit => Minimal Marketable Feature (MMF) ;
  • Une macro fonctionnalité => Feature.

Dans le cadre d’une activité de support et de maintenance d’une application en condition opérationnelle, cela pourrait être :

  • Pour les tickets d’incident => Urgence (Expedite) ;
  • Pour les demandes d’évolution => Standard ;
  • Pour les demandes à livrer à une date fixe => Date Fixe ;
  • Pour les tâches techniques => Intangible.

2 – Définir le Flux de Travail

Dès que chaque élément est identifié, vous pouvez mettre en lumière les étapes nécessaires à leur réalisation. C’est ce que l’on nomme « Le Flux de Travail ».

Le flux de travail peut être différent d’une organisation à l’autre et d’un métier à l’autre. Il le sera également au sein d’une organisation IT, entre notamment le marketing, un projet, une activité de maintenance ou un helpdesk.

3 – Identifier les files d’attente et les buffer

File d’attente

Une file d’attente permet de visualiser, au sein d’une activité (colonne) le travail en cours et les cartes en attente d’être « tirée » par l’activité suivante.

Par exemple : Développement En cours – Développement Terminé. L’étape « Développement Terminé » permet aux personnes intervenant sur l’étape suivante de savoir quels sont les éléments de travail disponibles pour être « tiré ».

La notion de file d’attente s’inscrit également dans le processus de limitation du WIP (Work In Progress – Travail en cours) et permet la mise en place d’un flux d’activité continue et adapté à la capacité à faire des différents intervenants.

Buffer

Dans son ouvrage « Kanban pour l’IT », Laurent Morisseau explique qu’un buffer représente une file d’attente sur laquelle les ressources ne sont pas immédiatement disponibles ou des activités ayant une cadence cyclique.

Le buffer représente également les interfaces d’entrée et de sortie d’un système kanban.

Personnellement, j’utilise la notion de buffer, pour les interfaces d’entrée (Backlog) et de sortie (Done) du système kanban et également sur la rupture entre la ou les phases de préparation des éléments de travail et l’étape de réalisation et de validation du dit élément (exemple : Maturation – Développement – Déploiement).

Crédit : Yannick Quenec’hdu

Format des cartes & Tableau Kanban

1 – Format de vos Cartes Kanban

Pour chaque type d’élément de travail identifié, vous devez définir les informations qu’il devra contenir, afin d’assurer son suivi et sa gestion dans de bonne conditions. Une Feature ne contiendra pas les mêmes information qu’une Story, qui n’aura pas les mêmes information qu’une demande support ou une anomalie.

Distinguez aussi chaque types de demande par une couleur distincte, afin de rendre votre tableau Kanban facilement lisible.

2 – Tableau Kanban

Après avoir identifié le Flux de travail et définit le format de vos éléments de travail, vous pouvez mettre en place votre Tableau Kanban, afin de visualiser l’ensemble de votre flux d’activité.

3 – Définir les règles de vie de votre Système Kanban

Un Système Kanbann peut être vu comme une autoroute. Une autoroute possède des règles permettant d’assurer le fonctionnement du flux et de garantir la sécurité des conducteurs en utilisant un langage commun.

Plus haut nous avons vu qu’un Système Kanban devait posséder des règles aux interfaces, en entrée et en sortie du Système. Ces seules règles ne suffisent pas à un fonctionnement optimal.

Voici les autres règles à mettre en oeuvre :

  • Les règles internes (gestion interne du flux de travail).
    • L’objectif est de définir les règles de fonctionnement de l’équipe, à l’intérieur du Système Kanban.
    • Exemples de règles internes :
      • Qui est responsable de chaque étape du workflow ? (ex. : un Dev ne peut pas valider son propre code en Test).
      • Définition des critères d’entrée et de sortie (DoR & DoD) pour chaque colonne Kanban.
      • Gestion du Work In Progress (WIP Limits) et résolution des goulets d’étranglement.
      • Règles d’attribution des tâches (ex. : les tâches les plus anciennes sont traitées en premier sauf exceptions).
      • Réunions internes pour suivre l’amélioration continue (ex. : un « Operations Review » toutes les 2 semaines).
  • Les règles de priorisation (comment trier et classer les tâches).
    • Cette règle permet de définir quelles seront les règles de priorisation dans la prise en charge des demandes. Cela peut être au travers de la priorisation affectée à un ticket (Mineur – Moyen – Urgent) ou en utilisant la notion de Classes de Service.
  • Les règles de purge (nettoyage du backlog et des tâches obsolètes).
    • Comme la chambre d’un ado, un Système Kanban mal géré devient rapidement un cimetière de tâches oubliées. Il faut instaurer des règles de purge régulières pour garder un système propre et efficace.
    • Exemples de règles de purge :
      • Suppression des tâches inactives après un certain temps (ex. : une tâche restée en backlog depuis 3 mois est supprimée si elle n’a pas été réévaluée).
      • Archivage des tâches terminées après X semaines (ex. : suppression des tâches « Terminées » après 2 mois pour alléger la vue du tableau).
      • Règle de validation des tâches avant suppression (ex. : un Product Owner doit valider avant qu’une tâche soit purgée).
      • Revue du backlog toutes les 4 semaines pour décider si les tâches sont encore pertinentes.
  • Les règles d’escalade (gestion des blocages et urgences).
    • L’une des activité les plus importante dans la gestion d’un Système Kanban et la suppression des obstacles. Tous les obstacles ne se valant pas et ne nécessitant pas l’intervention des mêmes acteurs, il est primordial de définir les règles d’escalade, afin de gagner en réactivité et d’éviter toute tension inutile, du genre envoyer un mail au Manager et à la moitié de l’entreprise dès que le moindre problème survient.
    • Exemples de règles d’escalade :
      • Quelles tâches nécessitent une escalade ? (ex. : une tâche bloquée depuis 48h doit être signalée à un responsable).
      • Qui doit être informé en cas de blocage ? (ex. : le Product Manager, le Manager IT, un Lead Dev).
      • Quels délais maximaux sont acceptables avant d’escalader ? (ex. : une tâche en Test bloquée plus de 3 jours est automatiquement priorisée).
      • Utilisation de labels ou d’indicateurs visuels pour signaler une tâche bloquée (ex. : un flag est ajoutée à une carte Kanban dans Jira).
      • Création d’un canal Slack/Teams dédié aux escalades urgentes.

Gérer votre Flux

1 – Flux tiré

Le Flux Tiré (Pull System) est un principe fondamental de la Méthode Kanban. Il permet à l’équipe de ne traiter les demandes que lorsque leur capacité à faire le leur permet et que le travail sur lequel elle était est terminée. Ce principe s’oppose au Flux Poussé (Push System) qui ne tiens pas compte de la capacité à faire de l’équipe et provoque des stocks, des goulets d’étranglement, le multi-tâches et au final un baisse de la capacité de l’équipe à tenir ses promesses et à livrer des éléments apportant de la valeur.

2 – Gérer les limites Hautes & Basses

Dans un Système Kanban les limites permettre d’adapter l’activité de l’équipe à sa capacité à faire.

Les limites peuvent être définies sur une étape du flux (interface, activité, buffer, file d’attente), une Classe de Service, Un type d’élément de travail, …

Une limite haute permet de ne pas traiter dans une étape plus d’élément de travail que sa capacité ne peut l’accepter. Elle permet également d’alerter l’équipe sur la génération d’un goulet d’étranglement.

Une limite basse assure à l’équipe de ne jamais être en sous-activité et ainsi perde de la productivité.

Comment identifier les limites à appliquer ?

L’un des principal moyens de définir les limites et de se baser sur la mesure des Flow Metrics, comme le débit moyen par étape du flux et le Cycle Time (Temps de traitement), notamment avec le principe de la Loi de Little (nous détaillerons ce sujet dans la partie 3). Cette pratique nécessite néanmoins d’avoir suffisamment d’historique pour mesurer la santé du flux.

Mais comment faire lorsqu’une équipe débute une nouvelle activité avec un Système Kanban ?

Une méthode, non officielle mais que j’utilise régulièrement est la suivante :

  • Limite Haute : (Nombre de personne intervenant dans l’étape * 2) – 1. Exemple : 3 personnes dans l’étape de développement. (3*2)-1 => La Limite Haute sera de 5
  • Limite Basse : (Nombre de personne intervenant dans l’étape – 1. Exemple : 3 personnes dans l’étape de développement. 3 -1 => La Limite Basse sera de 2

Les Cadences

La Méthode Kanban n’est pas aussi prescriptive que le cadre Scrum sur l’organisation du suivi des activités, ainsi que sur le cycle de réalisation.

C’est à l’équipe, en fonction de ses activités, de son contexte et de ses objectifs de définir quelles sera la cadence des différentes activités.

Contrairement à Scrum, un Système Kanban n’a pas d’obligation de synchroniser l’ensemble des cérémonials sur le même cadencement.

Les cérémonials Kanban

En Kanban, il n’existe pas de cérémonies strictement définies comme en Scrum (Sprint Planning, Daily, Review, Retro). Cependant, certaines réunions sont fortement recommandées pour assurer un bon suivi et une amélioration continue du flux de travail. Voici les principales réunions adaptées à un contexte IT

Crédit : Kanban University

Réunion de Réapprovisionnement (Replenishment Meeting)

  • Fréquence : Variable (ex. hebdomadaire ou bi-hebdomadaire selon le contexte)
  • Objectif : Sélectionner les nouvelles tâches à entrer dans le système en fonction des priorités, des capacités et des critères de gestion du flux.
  • Participants : Product Owner, Business, Équipe de développement, éventuellement des parties prenantes.
  • Contenu :
    • Revue du backlog et des nouvelles demandes.
    • Sélection des éléments à déplacer dans la colonne « À faire ».
    • Alignement avec les objectifs business.

Planning de suivi des livraisons (Delivery Planning Meeting)

  • Fréquence : Variable (La fréquence de cette réunion dépend du contexte de l’organisation et du volume des livraisons.)
  • Objectif : Définir les objectifs stratégiques pour garantir une livraison fluide et efficace des tâches en cours.
  • Participants : Delivery Manager / Kanban Coach ; Product Owner / Business Analyst ; Développeurs / Testeurs ; DevOps / Release Manager ; Service Support / Exploitation
  • Contenu :
    • Aligner les équipes sur les prochaines tâches à livrer et leurs dépendances.
    • Optimiser le flux de travail en identifiant et débloquant les tâches critiques.
    • Évaluer la capacité de l’équipe et ajuster les priorités si nécessaire.
    • S’assurer que les livraisons respectent les engagements pris envers les parties prenantes (métier, clients, utilisateurs).

Réunion de Révision du Flux (Flow Review)

  • Fréquence : Hebdomadaire ou bi-mensuelle.
  • Objectif : Évaluer la performance du flux de travail en analysant les indicateurs clés (Lead Time, Cycle Time, WIP, Throughput).
  • Participants : Équipe de développement, Product Owner, Managers.
  • Contenu :
    • Analyse des métriques (Cumulative Flow Diagram, Control Chart…).
    • Identification des goulots d’étranglement.
    • Discussion sur les ajustements nécessaires pour optimiser le flux.

Stand-up Meeting (Daily Kanban ou Kanban Huddle)

  • Fréquence : Quotidienne (souvent en début de journée).
  • Objectif : Synchroniser l’équipe sur l’état du travail en cours et identifier les blocages.
  • Participants : Équipe de développement.
  • Format :
    • Focus sur le travail (et non les personnes comme en Scrum).
    • Parcours du Kanban board de droite à gauche (travail le plus avancé en premier).
    • Discussion sur les blocages et les priorités.

Réunion d’Amélioration Continue (Kaizen / Service Delivery Review)

  • Fréquence : Mensuelle ou ad hoc.
  • Objectif : Identifier les améliorations possibles dans le flux de travail et les pratiques d’équipe.
  • Participants : Équipe de développement, Coach Agile, Managers si nécessaire.
  • Contenu :
    • Analyse des inefficacités dans le flux.
    • Proposition et expérimentation de nouvelles pratiques (ajustement des WIP, amélioration des policies, adaptation du board…).
    • Réflexion sur la qualité et la satisfaction des clients internes.

Operations Review (Revue Stratégique)

  • Fréquence : Mensuelle ou trimestrielle.
  • Objectif : Examiner la performance globale des différents flux de travail et leur alignement avec les objectifs stratégiques.
  • Participants : Managers, Équipes transverses, Responsables Produit, Stakeholders.
  • Contenu :
    • Analyse de la capacité et de la demande.
    • Ajustement des priorités et des ressources.
    • Coordination entre plusieurs équipes ou services.

Strategic Review

  • Fréquence : Trimestrielle ou Semestrielle
  • Objectif : Aligner les objectifs stratégiques de l’entreprise avec le fonctionnement du système Kanban.
  • Participants : Direction, C-Level, Sponsors, Portfolio Managers, Product Owners.
  • Contenu :
    • Vérifier que les initiatives en cours sont alignées avec les priorités business.
    • Evaluer l’efficacité des flux de travail par rapport aux objectifs stratégiques.
    • Identifier les besoins en ressources, en compétences ou en investissements.
    • Définir les prochains grands chantiers pour améliorer la chaîne de valeur.
    • Prioriser les initiatives à fort impact pour l’organisation.

Aller plus loin

La démarche STATIK

La démarche STATIK (Systems Thinking Approach to Introducing Kanban) est une approche structurée proposée par la Kanban University pour implémenter efficacement un système Kanban au sein d’une organisation. Elle a pour objectif d’analyser en profondeur le fonctionnement actuel d’un service et de concevoir un Système Kanban adapté aux besoins spécifiques du flux de valeurs.

STATIK est composé de 6 étapes de mise en oeuvre d’un Système Kanban.

Pour en savoir plus sur cette démarche, n’hésitez pas à consulter la Guide officiel de la Méthode Kanban, proposé par la Kanban University.

Conclusion

Comme vous l’avez constaté, un Système Kanban ne se limite pas à des colonnes et des tickets. un travail d’introspection est nécessaire, de la part de l’ensemble des acteurs d’une équipe ou d’une organisation. C’est une transformation progressive qui repose sur une observation fine du flux de travail, une optimisation continue des processus et une implication active des équipes.

En suivant les étapes décrites dans cet article, une organisation peut structurer un Kanban performant et évolutif, adapté à ses besoins spécifiques et l’améliorer en continue.

Dans le prochain article nous nous intéresserons aux Flow Metrics à mettre en oeuvre dans un Système Kanban, afin de répondre à la troisième pratique « Mesurer et Gérer le Flux« .