Le framework Scrum domine les implémentations d’Agile aujourd’hui. Dans leur dernière étude, VersionOne montre que 76% des entreprise l'utilisent ou l'adaptent. C'est donc sans surprise que lorsque nos consultants sont allés à la conférence Lean Kanban France 2017, ils ont redécouvert cette approche alternative. De nombreuses questions se sont posées. Je vous propose de répondre à ces questions dans une série d’articles sur Kanban.

Qu’est-ce que c’est et comment le mettre en place ?

Kanban est une pratique qui vient de Lean. Il se traduit littéralement par “panneau d’affichage”. Il n’est pas surprenant de voir des équipe jouer avec des post-it et se dire “utiliser kanban”. L’approche est cependant plus rigoureuse.

Dans une courte vidéo sur l’utilisation de Kanban en hôpital, l’interlocuteur défini Kanban: “Un système de planification utilisé pour approvisionner les étagères de produits médicaux au bon moment, basé sur ce qui est utilisé. L’objectif est de s’assurer que les employés ont à disposition les bons produits au bon moment.” Dans le milieu informatique, l’approche Kanban cherche à fournir les bonnes informations et ressources aux ingénieurs, pile au bon moment. Cela permet un flow de développement continu, de l’idée à la mise en production.

La mise en place d’un tel système se fait en trois étapes :

• Visualiser le processus de développement et le travail en cours
• Limiter l’encours
• Améliorer continuellement.

Visualiser le processus de développement et le travail en cours

Romain Couturier, lors de sa keynote, propose une série d’ateliers pour les découvrir. Déterminez votre produit, puis le processus de développement, et enfin identifiez les tâches qui sont en cours de développement ou en attente.

Afin de déterminer votre produit, posez vous les questions suivantes :

• Qui sont les gens dans votre équipe ? Séparez clairement ceux avec qui vous travaillez quotidiennement et les autres.
• Qui votre équipe sert-elle ? Ces personnes sont vos clients.
• Quelles sont les demandes des vos clients à votre équipe ? Voilà votre produit.

Une fois que vous connaissez votre produit, vous pouvez découvrir votre processus de travail.

• La fin de votre processus est nommé “livraison”.
• Quelle activité est nécessaire juste avant de livrer ? Notez la juste avant la livraison.
• Quelle activité est nécessaire juste avant celle ci ?
• Continuez à investiguer les activités jusqu’à trouver “le Client demande xxx”

Enfin, créez un grand tableau sur un mur blanc. Pour chaque activité que vous avez découvert dans l’atelier précédent, faites deux colonnes, une “en cours” et une “terminé”. Avec votre équipe, prenez des post-its et inscrivez toutes les activités que vous êtes en train de faire ou qui sont en attente, et affichez les sur le mur.

Bravo ! Vous avez visualisé votre processus de développement et le travail en cours ! C’est la première étape pour construire votre Kanban. Si vous faites trois pas en arrière, vous pouvez sans doute déjà repérer les plus gros problèmes de votre système. En créant de la transparence, Kanban vous permettra d’inspecter facilement votre processus et de l’adapter là où c’est nécessaire.

Limiter l’encours

Pour chaque étape de votre processus de développement, choisissez une limite. Cette limite correspond au nombre maximum de travaux “en cours” ou “terminés” pour cette étape. Respectez cette limite, et vous avez votre système Kanban qui fonctionne !
Comment trouver cette limite ? Il n’y a pas de “recette miracle” ou de “formule mathématique” pour cela. Le plus simple est de regarder le tableau que vous avez créé et de mettre pour limite le nombre de tâches affiché. Votre amélioration continue se chargera de “fine tuner” cette limite.

Et maintenant ? C’est là que la difficulté commence. Prenons un flux de développement classique pour exemple. Les processus pourraient être chaînés comme il suit : Idée, spécification, développement, test, déploiement, livré. Admettons que vous ayez une limite de 8 développements, et 3 tests.

Lorsque l’équipe a développé 8 tâches, si votre testeur est trop lent, votre tableau ressemblera à ça :

En suivant les règles de la limitation du travail en cours, vos développeurs sont maintenant désoeuvrés. Il leur est interdit de commencer une nouvelle histoire utilisateur. Blasphème! me direz-vous ? Non, si on y réfléchit plus longtemps, c’est logique.

Votre testeur n’arrive pas à suivre le rythme des développeurs. Bravo : vous avez identifié un goulet d’étranglement de votre flux au niveau du testing. Plutôt que de pousser plus de stories vers les tests, il est plus sage de demander aux développeurs pour faire sauter ce goulet d’étranglement. Ils peuvent le faire de plusieurs manière, en respectant leurs compétences :

• Augmenter la qualité sur les stories en attente. L’idée est que si le développeur passe plus de temps sur ses stories, le testeur trouvera moins de bugs et la stories sera déployée plus tôt.
• Développer des outils pour faciliter le tests
• Identifier des données de tests
• Créer des tests automatisés
• Faire une partie des tests. Ceci est souvent le dernier choix, car un développeur n’a pas les mêmes compétence qu’un bon testeur
• Travailler sur l’amélioration continue des tests
• A vous d’en imaginer d’autres…
  Le point important est d’interdire aux développeur de développer. Ce point est critique, et souvent la raison de l’échec de l’introduction de Kanban dans les équipes de développement.

Améliorer continuellement

L’amélioration continue est au coeur du système. Comme nous l’avons vu, l’introduction du système oblige certaines personnes à s’arrêter de travailler sur le produit, et à travailler sur l’amélioration. Ce n’est pas la seule méthode d’amélioration proposée par le Lean.

Lean propose de nombreuse techniques. Énumérons en quelques unes :

• Red Bin
• Kaizen
• Stand in a circle
• Gemba walk
• Standardisation
• PDCA

La liste est longue, et nous les décrirons plus en détails dans un prochain article. Avec tous ces outils à votre disposition, pensez-vous avoir toujours besoin de votre rétrospective hebdomadaire ?

Pensez-vous mettre en place Kanban pour vos équipes ? Faites-nous vos retours !