Kanban en 4 étapes

La méthode Kanban est une méthode simple, visuelle et compréhensible par tous les acteurs d’un processus. Elle est également faiblement intrusive dans l’organisation, contrairement à Scrum qui définit de nouveaux rôles (Product Owner, ScrumMaster), de nouveaux artéfacts (Product et Sprint Backlogs), une cadence figée (Sprints) et des cérémonies dédiées (Planning meeting, Sprint Review, etc…).

Kanban est simple, mais sa mise en œuvre nécessite un peu de méthode et beaucoup d'accompagnement. Je vous propose dans cet article de décrire la démarche que j'ai implémentée sur l'un de mes projets. J'ai volontairement essayer d'en faire ici une démarche générique et non spécifique.

Kanban en 4 étapes

Pour démarrer avec Kanban, pas besoin de big bang. On part du processus existant, et on itère sur la mise en oeuvre, de manière progressive. On se focalise d’abord sur un flux simple ou un sous-flux, en limitant le nombre de nouveaux concepts à implémenter et appréhender. La montée en puissance de Kanban se fera alors par l’enrichissement progressif des concepts mis en oeuvre et par l’élargissement des acteurs impliqués.

Les pré requis

Afin d’impliquer l’ensemble des parties prenantes concernées par le processus global, la mise en œuvre de Kanban est conditionnée par l’identification

• D’un facilitateur (pilote opérationnel du processus à "kanbaniser", qui peut être externe à l’organisation)
• D’un sponsor (obligatoirement interne à l’organisation et avec le bon niveau de décision et d’entrainement de l’ensemble des parties prenantes)

Etape 1 : Modéliser le flux existant

La première étape part de la situation réelle. Elle consiste à modéliser le flux existant, en identifiant la typologie des éléments de fabrication (ou classes de services), les étapes du processus au travers desquelles voyage chaque instance d’élément de fabrication, et les acteurs associés à chaque étape.

Il s’agit d’un découpage à la fois horizontal et vertical :

• horizontal : la typologie des éléments de fabrication ou des services à fournir (évolution fonctionnelle, travaux techniques, correction d'anomalie, …) ainsi que leur complexité, qui doit être réduite à un nombre limité de taille (XS, S, M, L, XL)
• vertical : les séquences d’activités (ou étapes) nécessaires à la fabrication des éléments ou à la fourniture du service (analyse, spécification, conception, développement, acceptation, production) et les acteurs associés à chaque étape.

Une fois le modèle existant identifié, il est retranscrit sur le tableau Kanban, visible de tous, et permettant de mettre en œuvre le management « visuel » du processus.

Etape 2 : Implémenter ou tuner les concepts

Les concepts associés à Kanban sont en nombre limité et assez simple à appréhender. Il s’agit de :

• La visualisation du workflow (une étape est représentée par une colonne sur le tableau Kanban)
• Le transit des éléments de fabrication (représenté sous forme de cartes Kanban avançant de colonne en colonne, et dont la couleur reflète la typologie)
• Le travail en cours (WIP - Work In Progress), type de colonne regroupant les éléments réellement en cours de fabrication par une équipe dédiée (TEC : travail en cours)
• Les files d’attente, représentant un stock de travail pour une équipe dédiée, qui vient « tirer » son activité de la finalisation de l’étape amont (TAF : travail à faire)
• Pour chaque colonne, la détermination des limites (hautes et basses) à ne pas dépasser, c’est-à-dire un nombre maximum ou minimum d’éléments de fabrication transitant au même moment par une même colonne (travail en cours ou files d’attente)

Si le workflow et la typologie d’élément de fabrication varie généralement peu, les limites elles peuvent varier en fonction de l’apprentissage de chaque équipe, de l’amélioration continue ou d’un changement capacitaire.

Chaque limite doit être tunées en permanence :

• Pour les files d'attente, afin d’éviter de travailler de manière trop anticipée, lisser la charge et limiter le stress d’une pile de tâche qui s’accumule. La limite doit être suffisamment grande pour garder l'équipe occupée, mais suffisamment petite pour éviter que des éléments stagnent trop longtemps avant d'être traités.
• Pour le travail en cours, principalement pour empêcher le multitâche. En effet, le multitâche est générateur de perte en ligne car passer d’une tâche à une autre implique obligatoirement une certaine inertie et ralentie le débit global. De plus, il est plus bénéfique pour l’équipe de garder le focus et l’attention sur un nombre limité de travaux, et améliorer ainsi les échanges, le travail d'équipe et la diffusion de la connaissance.

Etape 3 : Faire couler le flux

Il est important de noter que les éléments qui transitent au travers des colonnes WIP et files d’attente sont toujours des notions liées au besoin du consommateur final du processus (flux tiré). La granularité des éléments n’est donc pas la tâche (work), mais la fonctionnalité (feature). La feature est bien la finalité et la valeur intrinsèque du processus lui-même.

Pour démarrer le flux, il faut donc instancier les éléments qui vont couler le long des étapes.

• Pour le BUILD (réalisation d’une application ou d’une évolution majeure), on découpe le périmètre en petit bout (Feature Breakdown Structure OU Story Mapping -> Product Backlog) et on le priorise,
• Pour le RUN (activité récurrente type correctif ou incident), le flux démarre de manière événementielle, ou avec un stock priorisé (P1, P2, P3).

Le flux coule naturellement grâce aux limites. Une équipe à droite tire son travail à faire de l’équipe à gauche dès que sa limite le lui permet. La priorisation peut être issue de règles de gestion associées à la typologie des éléments de fabrication, où décidées par qui de droit. En effet, bien que Kanban n’implique pas la définition de rôles précis, il est souvent nécessaire de déterminer un « propriétaire du produit » ou un « responsable opérationnel du flux  » qui est à même de décider de la priorisation de l’activité.

Etape 4 : Collaborer et s’améliorer

Cette dernière étape permet de mettre en place quelques pratiques supplémentaires pour faciliter la collaboration et l’amélioration continue, et de reboucler sur l’introduction ou l’adaptation des concepts Kanban au contexte.

Les pratiques complémentaires à Kanban ne sont pas limitées. En voici quelques exemples:

• Le stand-up meeting
• La rétrospective
• Les DoD et DoR
• L’Emergency Line

Stand-up meeting

Le pilotage est dans le rythme (et vise-versa). Chaque jour, un stand-up est organisé autour du tableau Kanban et réunit les intervenants concernés par les différentes activités du flux. Ce stand-up a pour objectif de piloter le Kabnan, et mettre à jour « l’instantané » de l'état du processus que constitue son tableau.

L’implication de chacun est un élément fondamental de la réussite d’un projet, et le facilitateur Kanban doit s’assurer du bon degré de collaboration et du bon niveau de connaissance de chacun. C’est lui qui s’assure du bon déroulement de la réunion, qui doit être time-boxée.

Durant ce stand-up, on passe en revue l’activité de chaque équipe (via son représentant présent). On débute en partant de la droite du tableau – le besoin final. Pour chaque activité, trois points sont abordés (équivalent des trois questions du Daily Scrum) :

• L’activité en cours pour chaque équipe
• L’activité à venir pour chaque équipe, et la priorisation de l’activité
• Les obstacles à venir, et les actions de prévention

Dans ce processus collaboratif, la notion de limite spécifiée pour chaque colonne est primordiale. Et il est important de considérer que les limites sont des règles de gestion du processus pour lesquelles on ne transige pas.

En effet, les limites constituent le moyen d’identifier très rapidement les problèmes du système, qu’ils soient récurrents ou exceptionnels (blocage, engorgement, sous-activité). 

Lorsqu’une limite est atteinte, la première conséquence est qu’aucun nouvel élément de fabrication ne peut entrer dans la colonne en question. Il y a donc urgence à « désengorger » l'activité, au risque de bloquer l’ensemble du système.

L’atteinte d’une limite doit donc déclencher immédiatement deux choses :

• La focalisation sur l’activité en risque de surcharge
• L’affectation prioritaire des ressources sur le déblocage de l’activité

Dans ce cadre, et si cela est possible en fonction des connaissances de chacun ou du mode de contractualisation entre les équipes, les ressources des autres équipes doivent venir en renfort de l’équipe où la limite est atteinte.

Rétrospectives

Pour améliorer le processus et/ou le produit, il est plus bénéfique de « décrocher » de l’activité opérationnelle et prendre un peu de recul. C’est la raison pour laquelle il est préférable d’aborder l’optimisation et l’amélioration continue lors d’ateliers dédiés plutôt que de mixer des réflexions d’amélioration au suivi quotidien de l’activité.

L'outil ici, c'est la rétrospective. Tout comme le stand-up meeting, un maximum de parties prenantes doit participer aux sessions de rétrospective. Typiquement, deux questions y sont évoquées:

• Qu’est-ce qui fonctionne bien et qu’il faut capitaliser ?
• Qu’est-ce qui fonctionne moins bien et qu’il faut améliorer ?

Pour être efficace, des décisions concrètes et partagées doivent émerger de chaque rétrospective. Les plans d'actions doivent être réellement menés. 

DoR / DoD : Definition of Ready & Definition of Done

L’entrée d’un élément dans le processus de fabrication, comme le passage d’un élément de fabrication d’une colonne WIP à une colonne de file d’attente doit correspondre à un contrat passé entre l’équipe qui fournit (à gauche) et l’équipe qui consomme (à droite). L’équipe qui fournit doit se focaliser sur la satisfaction de son client (l’équipe que consomme) et livrer son travail conformément à ce qui est attendu.

Les DoR et DoD définissent ces contrats. Ils stipulent que si un élément est présent dans une colonne de type « file d’attente », c’est que cet élément est dans un état correspondant à l’accomplissement par l’équipe amont d’un certain nombre de tâche sur cet élément. 

Une bonne pratique est d’afficher les DoR et DoD en-dessous de chaque colonne « file d’attente ». Ces définitions ne sont pas figées, et peuvent évoluer avec le temps, en augmentant progressivement le niveau d’exigence.

Emergency Line

Le processus doit pouvoir gérer les urgences. Une équipe doit pouvoir travailler sur une urgence, même si sa limite est atteinte.

On peut dès lors insérer une ligne spéciale (emergency line) dans laquelle ne peut circuler qu’un élément en parallèle. Un élément présent dans cette colonne indique à l’équipe que c’est sa priorité du moment.

Attention toutefois bien définir collectivement ce qu’est une urgence, car beaucoup voudront alors considérer que « tout » est urgent afin de voir leur besoin propre avancer plus vite.