Dans notre précédent article nous avons vu POURQUOI l’équipe dev-clients a choisi de passer du Scrum au Kanban. J’aimerais revenir ici sur le COMMENT, comment nous avons changé de méthode de travail pour améliorer notre processus de développement et répondre aux besoins de nos clients. Je vous propose donc de détailler les différentes pratiques du Kanban que nous avons mises en place et de voir comment chacune d’entre elles a permis à l’équipe de s’améliorer.

Visualiser le flux pour collaborer plus efficacement

GO WITH THE FLOW

Le flux de production comporte l’ensemble des étapes nécessaires à la création de valeur et à la satisfaction des besoins de nos clients. Le flux optimal est donc celui où l’on passe d’une étape à l’autre sans aucun ralentissement ni blocage : chaque étape produit un incrément de valeur, l’équipe travaille juste à temps, au bon moment et en fonction de ses capacités, ni plus, ni moins.


Un peu d’histoire

Kanban (カンバ) est un terme d’origine japonaise que l’on peut traduire par étiquette ou fiche cartonnée. Le système Kanban est quant à lui né dans les années 1950 au sein de l’usine Toyota et désigne une méthode de gestion des stocks en flux tendu permettant de produire le produit demandé, au moment où il est demandé et dans la quantité souhaitée. En 2001, c’est Mary et Tom Poppendieck dans leur description du Lean Software Development qui évoquent les premiers le système kanban au sein du développement logiciel pour pouvoir livrer continuellement et de façon croissante de la valeur métier, dans le temps le plus court possible et en dépensant de moins en moins d’effort et avec la meilleure qualité possible. L’atteinte d’un tel objectif passe par la réduction du Muda (terme japonais pour gaspillage) : les activités qui consomment des ressources mais n’apportent pas de valeur au client final.


La première étape a donc été pour l’équipe de “poser son flow”, de réfléchir aux différentes activités du processus existant et d’identifier :

  • les différentes activités conduites par l’équipe
  • les interactions existantes entre les développeurs
  • les demandes effectuées par les parties prenantes auprès de l’équipe et leurs critères de (in)satisfaction
  • les difficultés et ralentissements existants dans le process actuel

Cette nécessaire prise de recul sur notre façon de travailler au quotidien nous a permis de modéliser un premier flux de travail que nous avons matérialisé sur notre board physique. Cette photographie à un instant T de la réalité du terrain a bien sûr évolué au gré des changements de process, des propositions de l’équipe, des difficultés rencontrées ou des besoins clients !

Notre premier board kanban
Notre board quelques itérations plus tard

Limiter le travail en cours pour arrêter de commencer et commencer à finir

NO LIMIT ?

Le travail en cours, le Work In Progress (WIP), comprend l’ensemble des éléments inachevés que l’équipe doit réaliser pour apporter de la valeur au client final. Il comprend les travaux sur lesquels les développeurs travaillent concrètement en ce moment, les tâches en attente de vérification ou déployés et même le travail préparatoire à mener en amont. Limiter le WIP c’est donc déterminer la quantité maximale de travail que peut absorber l’équipe à chaque étape du flux de production.

Après plusieurs jours de travail sur notre nouveau Kanban, une simple observation du board a permis à l’équipe de visualiser la surcharge de travail en cours sur sa phase de relecture de code : on commençait plus que l’on ne terminait ! Il nous a donc fallu choisir une limite haute qui oblige les développeurs à finaliser les reviews avant de s’engager sur une nouvelle tâche de développement. Au fur et à mesure des obstacles rencontrés, l’équipe a inscrit de nouvelles limites pour les différentes étapes de notre flux.

En limitant la quantité de travail en cours on accélère la capacité de production de l’équipe et on réduit le temps de traversée moyen des éléments au sein du board. Poser une limite engage l’équipe dans une démarche d’amélioration continue. En effet, les limites questionnent, elles provoquent des frottements et facilitent le changement. C’est un formidable outil pour visualiser les problèmes, échanger sur les raisons qui provoquent des goulots d’étranglement et proposer des solutions pour lever les blocages du flux de travail.

Des embouteillages en cours sur la review

Optimiser le flux pour s’améliorer collectivement

BREAK THE RULES

Kanban n’est pas une méthode prescriptive et ses règles de gestion sont ouvertes. L’essentiel est donc de “commencer là où on en est” et c’est à l’équipe de définir quels sont les rôles, les processus et les règles à mettre en place pour pouvoir augmenter la qualité de ce qu’elle délivre. Ces règles doivent être explicites pour assurer une compréhension partagée du travail en cours et faciliter l’amélioration continue (le management visuel est alors d’une grande aide !).

Au sein de l’équipe, les différentes règles ont émergé au fur et à mesure des problèmes rencontrés ou de l’émergence de nouveaux besoins proposés par les développeurs pour mieux travailler ensemble :

  • distinguer la nature des tâches à l’aide des couleurs de post-it : les User Story en jaune, les bugs en rose, la dette en orange et les activités récurrentes en bleu.
  • formaliser les cartes en faisant apparaitre son titre, son numéro gitlab, le client concerné, la date d’entrée dans le board et son poids (ou sa criticité pour les bugs).
  • vérifier la Definition Of Done (DOD) avant de déplacer une carte d’une colonne à l’autre.
  • animer le board par des daily meeting et des rétrospectives pour rapporter les infos et permettre les changements.

Conclusion : le Kanban, un outil au service du changement

HARDER, BETTER, FASTER, STRONGER

La mise en place des 3 pratiques esquissées ci-dessus : visualiser, limiter, optimiser, suffit à une équipe pour se lancer dans le Kanban. Au sein de l’équipe Dev client les progrès observés ont été sensibles. Le board physique a fait des émules au delà même des équipes techniques et d’autres pôles se sont saisis de cet outil ! Si, au début, il n’a pas toujours été facile de convaincre les développeurs de limiter leur travail, les limites WIP ont été diminuées progressivement et permettent aujourd’hui de maximiser le Done. D’un point de vue qualitatif, le regard sur l’équipe a changé et l’ensemble des parties prenantes a conscience des améliorations ; aujourd’hui nous délivrons :

  • plus : nous avons augmenté notre vélocité de près de 40%
  • plus vite : nous n’avons pas de bugs supérieurs à 2 semaines dans notre backlog
  • mieux : l’explicitation de règles collectives et l’amélioration continue de nos outils nous permettent d’améliorer la qualité de ce que nous délivrons

La force de la méthode Kanban c’est sa capacité à s’adapter à de nombreuses organisations. En effet, à l’inverse du Scrum qui propose un cadre générique, le Kanban propose des pratiques non prescriptives qui facilitent l’amélioration continue. Mais encore faut-il laisser le temps aux équipes de construire ce cadre à travers un formidable outil qui fera l’objet d’un futur article : la rétrospective.