Vous cherchez un retour d’expérience pratique sur le système Kanban appliqué à un processus de développement : lisez “Kanban, Successful Evolutionary Change for Your Technology Business” de David Anderson. Ce livre, facile à lire bien que très riche, puise sa force dans son pragmatisme et ses exemples concrets : ça sent bon l’histoire vécue ! Le plaidoyer est parfois un peu trop partial avec des phrases du type “it works because its Kanban, because it just does…”, mais c’est un petit pêché qu’on pardonnera volontiers à son auteur.

De quoi s’agit-il ? Le kanban est une approche qui permet d’éviter certains travers du développement de type “waterfall”. Par exemple, la séquentialisation des activités et la lourdeur des versions retardent la livraison de la valeur au client final et rendent toute évolution dans les priorités très pénalisante. Le kanban repose sur la limitation du travail en cours à chaque étape du processus de développement. David Anderson explique, exemples à l’appui, la puissance d’un système en flux tiré dans un processus de développement IT. Il tire de son expérience plusieurs enseignements.

Tout d’abord, il recommande trois principes fondateurs :

• Commencez par un périmètre que vous maîtrisez : ne cherchez pas à optimiser un processus que vous ne connaissez pas suffisamment ou qui n’existe tout simplement pas tant il est aléatoire;

• Acceptez de faire évoluer les choses progressivement : le système Kanban, sous ses airs simples, est une mécanique extrêmement fine qui bouscule les pratiques opérationnelles et managériales. Le temps est donc votre allié;

• Respectez le processus en place comme les rôles, missions et titres de ses acteurs : tout imparfait qu’il est, le processus sur lequel vous allez travailler a produit un écosystème cohérent. L’enjeu du Kanban est de faire évoluer le flux de production : il n’est pas nécessaire de bouleverser l’organisation en place.

Ces précautions connues, il détaille les 5 propriétés clés d’un système Kanban :

• Visualiser le flux : dans un processus d’ingénierie, notamment logiciel, une grande partie du flux d’information entre acteurs est dématérialisée, ce qui nous empêche de voir où sont les problèmes. En rendant le flux visible, on rend évident pour tous les travers du processus : goulets d’étranglement, défauts, problèmes,…

• Limiter les travaux en cours : ce n’est pas en cumulant les évolutions ou les corrections simultanées que vous allez améliorer la qualité et le respect des délais. Plus vous limitez les encours, plus vite les travaux entamés aboutissent : la valeur est délivrée plus rapidement au client, il est plus aisé de revoir les priorités sur les travaux non entamés sans perturber le système (nous avons tous expérimenté une fois que revoir les priorités sur les travaux en cours vire vite au cauchemard),… La mise en place d’un flux tiré est le moyen le plus sûr de limiter les encours.

• Gérer le flux : l’enjeu est de prendre des mesures pour contrôler les délais à chaque étape et la rapidité de transfert d’une étape à une autre. L’enjeu est d’accélérer progressivement le flux pour délivrer la valeur plus vite.

• Expliciter les règles du processus : difficile de travailler sur un processus non formalisé. Cette formalisation doit permettre d’éclairer les pratiques en cours et servir de référentiel objectif pour faire évoluer ces pratiques.

• Améliorer en mode collaboratif et avec méthode : l’enjeu est de traiter les ressources “goulets” et la variabilité dans le processus en s’interrogeant sur la limite des encours souhaitables à chaque étape. Anderson suggère d’utiliser 3 méthodes scientifiques : la Théorie des Contraintes, la Théorie de la Connaissance Approfondie (une étude sur la variabilité et ses impacts sur un processus) et le Lean Management (la chasse au gaspillages). Ces méthodes permettent d’anticiper les impacts d’une évolution sur le processus étudié : en la matière, mieux vaut des bases solides que l’improvisation des talents.

Un bémol pour terminer : Anderson insiste peu, voire pas, sur l’importance de la dimension managériale dans le bon fonctionnement d’un système Kanban. Or la dynamique de transformation des postures et pratiques managériales est bien un facteur clé de résussite dans la durée : pas facile pour un manager d’accepter que tous les problèmes soient rendus visibles, qu’il ne faut pas lancer trop de choses en même temps alors que la pression est forte (métier, DSI),…
Une erreur est avant tout une opportunité d’amélioration ! David a ajouté dans son blog d’avril 2012 une sixième propriété clé : le leadership. Il n’est jamais trop tard pour mieux faire…