Après de 2 ans et demi d’une application fructueuse de SCRUM au sein d’une équipe de développement web, l’idée de passer à Kanban a germé comme un défi et une occasion de découvrir un nouveau mode de fonctionnement projet. Après plus de 6 mois de mise en pratique, le bilan est clairement positif ! Cet article propose un retour d’expérience mettant en avant les bénéfices, mais aussi les difficultés auxquelles nous avons été confrontés en passant à Kanban, et les solutions que nous avons mis en place pour y remédier.

Si vous ne connaissez pas Kanban, je vous suggère de regarder d’abord de quoi il s’agit ici avant de poursuivre la lecture de cet article.

 

CONTEXTE

En avant-propos, quelques éléments pour vous permettre de repositionner ce retour d’expérience dans son contexte. Je suis responsable d’une équipe d’une vingtaine de personnes chargée de développer des sites web. Nous travaillons en parallèle sur plusieurs nouvelles applications, ainsi que sur des évolutions et parfois des corrections d’anomalies sur une quinzaine de sites existants. La plupart des projets sont situés entre 250 et 500 JH de développement. Nous fonctionnons en agile depuis le départ et l’équipe a atteint un très bon niveau d’autonomie.

 

POURQUOI PASSER A KANBAN ?

J’ai découvert Kanban à l’occasion d’une partie de « Get Kanban » (un serious game que je vous recommande vivement pour découvrir Kanban), près d’un an avant d’envisager concrètement de changer de mode de fonctionnement. Bien qu’ayant trouvé le principe de ce mode de gestion de projet très intéressant, il ne m’avait pas semblé adapté à notre situation. Avant de passer à Kanban, il n’y avait pas de dysfonctionnement majeur ni d’insatisfaction exprimée sur notre mode de fonctionnement au niveau de l’équipe. Cependant, après deux ans et demi, une forme de routine s’était installée et la mécanique d’amélioration continue tournait au ralenti.

Par ailleurs, nous étions en train de nous orienter vers une logique de plus en plus multi-projet et multi-métier, et il devenait compliqué de donner du sens aux démos et aux plannings games pour les interlocuteurs métiers qui n’étaient de fait que partiellement concernés par ces instances.

L’idée d’essayer Kanban s’est donc imposée à la fois comme une opportunité d’essayer quelque chose de nouveau, mais également d’améliorer notre mode de fonctionnement multi-projets. J’ai donc proposé l’idée à l’équipe, et après une présentation de la méthode et une partie de « Get Kanban »*, nous avons pris la décision collective de tenter l’expérience.

* si vous souhaitez passer à Kanban, une partie de cet excellent jeux, précédée d’une présentation solide de la méthode est un pré-requis. http://getkanban.com/

 

KANBAN : LES POINTS POSITIFS

Le premier point positif de Kanban, c’est la souplesse. En supprimant les notions de sprint et d’engagement, et en définissant au fil de l’eau les items qui rentrent dans le flux de production, Kanban permet d’appliquer toutes les logiques de priorisation au moment opportun sans générer de débats ou de négociation sur le périmètre de l’itération. L’équipe reste focalisée sur le plus important : apporter de la valeur à nos métiers, le plus vite possible. Nous n’avions de toutes manières jamais appliqué Scrum de manière rigoriste, et toujours laissé la place à des changements opportuns en cours d’itération. Passer à Kanban a permis de réaligner notre mode de fonctionnement sur le réel. Par effet de levier, la mise en place de Kanban nous a permis de mettre en place une organisation d’équipe plus souple, avec plus de facilités à basculer des ressources d’un projet à l’autre en fonction des besoins.

Le second point positif, c’est l’arrêt de l’estimation des items en points de complexité. Bien qu’il soit tout à fait possible de maintenir cette estimation, l’équipe a fait le choix de se passer de cette étape qui ne lui apportait pas particulièrement de valeur, et qui suscitait parfois de longs débats au cours des planning games.

Nous n’avons pas réellement éprouvé les bénéfices associés à la limitation du travail en cours (WIP) dans chacun des états du processus de production, mais probablement parce que la manière de fonctionner préexistante de l’équipe était déjà globalement « saine » de ce point de vue. En revanche, la mise en place de Kanban a été l’occasion pour l’équipe de repenser et d’ajuster le cycle de vie et le processus de production, en améliorant la visibilité de la phase de conception fonctionnelle et la formalisation des tests croisés.

D’une manière générale, Kanban a donné un nouvel élan à la réflexion et à l’implication collective :

• En étant beaucoup moins précis que Scrum, Kanban a laissé davantage de place à l’équipe dans la définition des méthodes de production, cycle de vie, règles de fonctionnement, modalités d’interaction avec le Product Owner, etc.
• En apportant de nouveaux indicateurs partagés, Kanban a été l’occasion d’impliquer davantage l’équipe dans le suivi & maj des indicateurs au quotidien.

 

QUELQUES POINTS D’ATTENTION ET DES SOLUTIONS

Si le passage de Scrum à Kanban est globalement positif, certaines difficultés auxquelles nous avons été confrontées nous ont amené à faire évoluer notre fonctionnement pour apporter des solutions à ces différents problèmes.

Point d’attention : Perte de rythme

En premier lieu, le passage de Scrum à Kanban s’est traduit pas un ressenti de « perte de rythme ». Attention, je ne parle pas de baisse de productivité ! Celle-ci n’a été nullement impactée par le passage à Kanban, au contraire. En revanche, l’équipe a ressenti la disparition des sprints et du planning game comme une perte de points de repère.

Solution : Donner du rythme autrement

Sans itérations, il y a d’autres manières de conserver du rythme ! Nous avons maintenu toutes les instances de Scrum, à l’exception du planning game. Stand Up Meeting quotidien, rétrospectives et démonstrations à fréquence mensuelle. En particulier, le fait de programmer des démonstrations régulières génère des objectifs de livraisons intermédiaires à court terme appréciés par l’équipe et par les métiers.

 

Point d’attention : Perte de repères 

Les planning games étaient l’occasion de partager de manière assez détaillée le contenu de l’itération et la notion d’engagement constituait à chaque sprint un cap à atteindre. Le mode de fonctionnement « continu » de Kanban a donné le sentiment aux développeurs et à nos interlocuteurs métiers de perdre de la visibilité sur l’avancement des projets.

Solution : Systématiser l’approche « projet »

Mettre davantage en perspective les échéances des projets a également été un excellent moyen de donner du rythme aux travaux. Plus globalement, pour permettre à l’équipe et aux métiers de s’y retrouver dans un flux de production continu et multiprojets, nous avons systématisé une approche « projet » pour l’ensemble des travaux (hors MCO) afin d’y associer systématiquement un objectif de délai. Cette approche a permis de mettre en place des indicateurs systématiques d’avancement, partagés entre l’équipe et les métiers, à commencer par un burndown chart par projet mis à jour de manière hebdomadaire, complété par un story mapping permettant de mettre en évidence l’état d’avancement des différents blocs et, bien entendu, le backlog projet.

Autre effet bénéfique : muni d’une vision de l’avancement de tous les projets menés en parallèle, il est plus facile d’optimiser l’affectation des membres de l’équipe entre les projets et d’anticiper les besoins de ressources.

  

 

Point d’attention : Niveau de granularité du découpage des items du kanban 

Nous avons par ailleurs été confrontés à une problématique de granularité. L’équipe a choisi de réaliser un découpage fin des items suivis dans le Kanban, afin de permettre une parallélisation maximum. La quantité d’items générée par ce découpage, et la dimension « technique » apparente d’une majeure partie d’entre eux a perturbé la visibilité de nos interlocuteurs métiers sur nos activités et le lien avec les fonctionnalités demandées.

Solution : Maintenir un lien avec le backlog métier

Nous avons donc décidé de « masquer » cette volumétrie en gérant deux niveaux de granularité différents :

• Un niveau adapté pour suivre le périmètre et l’avancement du projet, avec un découpage à la maille « user story » ou « fonctionnalité », par exemple : « consulter la liste des factures », ou « se connecter ». C’est sur ce niveau de granularité que s’appuie le backlog projet et le burndown chart partagés avec entre l’équipe et le métier.
• Un niveau adapté au fonctionnement Kanban, correspondant à un découpage à la maille « tâche de développement », avec la condition que chaque item soit testable en soi par le PO. Afin de maintenir un lien systématique entre les activités de l’équipe et le backlog métier, les items gérés dans Kanban sont associés aux user stories comme des sous-tâches.

 

Point d’attention : disparition des points de complexité & nouveaux indicateurs

La disparition de la notion de points nous a obligés à revoir la plupart des indicateurs, basés sur les points, et la mise en place de nouveaux indicateurs de pilotage (temps de cycle, et Diagramme de flux cumulés (CFD) ) nous a laissé quelque peu dubitatifs au départ.

Solution : Privilégier une approche statistique pour le pilotage 

Nous avons compensé la disparition des points en adoptant une approche statistique pour le calcul des indicateurs « historiques » : vélocité, focalisation. La multiplication du nombre d’items, liée à une granularité plus fine du découpage des travaux, a largement contribué à obtenir un lissage statistique pertinent (et ça tombe bien, parce que Kanban fonctionne très bien avec un découpage fin). Nous avons constaté, avec une moyenne de 30 items par mois, que l’approche statistique est valable et que les indicateurs redeviennent pertinents. Pour ce qui est des « nouveaux indicateurs » spécifiques à Kanban : si la notion de temps de cycle ne nous est pas apparue vraiment pertinente dans notre contexte, le principe de faire transiter les items le plus vite possible a bien été assimilé par l’équipe comme un moyen d’optimiser le processus de fabrication et est le cycle time est suivi de près. Quant au CFD, il n’a fait qu’enrichir (et complexifier) le burnup chart d’itération que nous avions l’habitude de suivre quotidiennement dans le cadre de Scrum, et nous avons encore du mal à l’interpréter suffisamment précisément pour en tirer de la valeur ajoutée.

       

 

CONCLUSION

Le retour d’expérience, plus de 6 mois après le passage à Kanban, est globalement très positif ! Passer à Kanban a été un formidable moyen de redonner un nouveau souffle à l’équipe et de franchir un vrai cap en termes de mode de fonctionnement. Nous sommes maintenant parfaitement organisés pour faire du multi-projet, avec une capacité d’ajustement qui nous permet de couvrir les risques de manière très efficace, et un mode de pilotage qui donne à l’ensemble des parties prenantes (équipe, métiers) les bonnes informations pour suivre l’avancement des projets.

Certes, des ajustements réalisés au fil de l’eau ont été nécessaires, et nous avons encore le sentiment de ne pas tirer entièrement profit du potentiel de cette méthode. Mais après avoir senti les limites du cadre proposé par Scrum, passer à un mode de gestion beaucoup plus libre a été une vraie opportunité de progresser en termes d’agilité.

Le succès de cette transition s’est cependant beaucoup appuyé sur notre maturité agile. Elle n’aurait certainement pas été possible sans une réelle implication et une vraie capacité d’auto organisation de l’équipe. Pratiquer Kanban sans une expérience préalable de l’agilité (en particulier SCRUM) peut s’avérer périlleux et il ne faut pas hésiter à se faire accompagner* pour en tirer pleinement profit !

 

 

*(pour notre part, nous avons été accompagnés par Guillaume Lours et Alexandre Boutin)