Je travaille avec les approches Agile depuis maintenant près de 20 ans et je n’ai entendu parler de Kanban qu’en 2015, lorsque j’ai rejoint l’équipe de Pyxis. Je me suis immédiatement intéressée à cette « nouvelle forme » d’Agilité et, en tant que coach Agile, j’ai décidé d’en apprendre plus sur Kanban pour étoffer ma boîte à outils.

À la suite de nombreuses lectures, de discussions et de quelques expériences personnelles avec des équipes que je coachais, j’ai décidé de suivre une formation en bonne et due forme. J’ai suivi les cours Kanban System Design et Kanban Management Professional avant de partir pour Seattle et de suivre le programme Accredited Kanban Trainer de la Lean Kanban University. Les trois dernières années m’ont amené à penser que la méthode Kanban est une excellente approche pour accroître l’Agilité d’affaires des équipes de développement et d’opérations.

Les origines de la méthode Kanban

Le mot « kanban » signifie enseigne ou panneau de signalisation en japonais. Le système « tiré » de Kanban, inventé dans les années 40 par Taiichi Ohno, ingénieur industriel chez Toyota, est un système de planification de production Lean et « juste à temps » qui utilise des cartes pour signaler le besoin de réapprovisionnement. Dans un système Kanban « tiré », la demande tire la production de biens en maintenant efficacement des niveaux de stocks peu élevés, réduisant ainsi au minimum l’espace de stockage.

Avançons aux années 90, le mouvement Agile se développe rapidement, emprunte des idées à la culture Lean et aboutit en 2001 à la déclaration du Manifeste Agile, écrit par un groupe de dix-sept personnes, principalement des représentants d’Extreme Programming (XP) et de Scrum.

En 2004, David J. Anderson, inspiré par ses expériences Lean et Agile, a mis en œuvre le premier système Kanban virtuel pour soutenir l’ingénierie logicielle chez Microsoft. Après un succès fulgurant, Anderson est ensuite allé travailler à Corbis, où l’approche Kanban a commencé à voir le jour entre 2006 et 2008. Elle continue d’évoluer jusqu’à présent grâce à la croissance de la communauté de développement Lean de logiciels.

Une approche sous-estimée

De nombreuses idées fausses surgissent lorsque je discute de Kanban avec les gens. Ils croient souvent qu’il s’agit simplement d’avoir un tableau pour suivre le travail, sans objectifs réels et sans mesure. J’ai même déjà entendu : « C’est pour les équipes paresseuses. » Cela pourrait effectivement être le cas si une équipe improvise avec Kanban, mais tout comme d’autres approches Agiles, Kanban propose des pratiques spécifiques qui ont leur raison d’être. Si nous négligeons ces pratiques, nous nous retrouverons probablement avec un système imprévisible qui ne répond pas à nos besoins. C’est comme jouer à un jeu, quand on renonce à des règles importantes, les mécanismes du jeu finissent par ne pas fonctionner du tout! Mais il ne serait pas pour autant juste de dire que le jeu n’a pas de sens, n’est-ce pas?

Atteindre la viabilité

L’objectif de toute approche Agile est d’aider une entreprise à livrer plus souvent de la valeur, à avoir un retour sur investissement plus rapide et, au final, à gagner la partie sur le marché. La viabilité est la clé du succès. Nous voulons que les équipes apportent de la valeur aux clients fréquemment et continuellement.

Pour ce faire, nous devons réduire la taille des lots. Le sprint est un moyen de réduire la taille des lots. Les éléments sont sélectionnés à partir du carnet de produit ou d’équipe et ajoutés dans un carnet de sprint pour la durée de l’itération. Nous visons ensuite à livrer le travail sélectionné en respectant le temps imparti. Les sprints ne sont pas utilisés dans Kanban, mais la taille des lots est réduite en limitant la quantité de travail en cours (WIP) pour chaque étape du processus. Cette approche oblige l’équipe à terminer le travail en cours avant de commencer une nouvelle tâche.

Bandeau_Campus_Kanban

Prévisions et nécessité de recueillir un historique des données

Réduire les limites de WIP permettra également de stabiliser le flux de travail et de prévoir ce qui peut être livré au cours d’une période donnée. En premier lieu, les données doivent être collectées. Pour chaque itération, la vitesse de l’équipe peut être mesurée à l’aide de sprints. Ces renseignements peuvent être utilisés comme un outil de prévision du travail que la même équipe pourrait effectuer au cours de futures itérations.

C’est très bien, mais l’équipe ne peut pas être prévisible après un seul sprint. Selon mon expérience, plusieurs sprints (de 3 à 6) sont nécessaires avant que la vélocité ne devienne prévisible. En outre, pour calculer la vélocité de l’équipe, nous avons besoin d’un mécanisme de mesure, par exemple les story points. Les story points sont un système de mesure « fabriqué. » Ils ne sont pas une mesure réelle et ne signifient rien en dehors de l’équipe. Néanmoins, ils constituent un excellent outil pour une équipe capable de se concentrer uniquement sur le travail de son carnet de sprint.

L’inconvénient est que l’estimation de la taille relative de chaque tâche du carnet nécessite du temps. L’équipe l’effectue de manière ponctuelle au début de chaque sprint. Selon la longueur de ce dernier, cette activité peut prendre une journée de travail entière.

Lorsqu’on utilise la méthode Kanban, il faut également recueillir un historique des données avant que la vitesse ne devienne prévisible. Cependant, l’équipe n’a pas besoin de passer autant de temps à effectuer l’estimation. Plutôt que d’utiliser un système de mesure fabriqué, dans Kanban nous mesurons des données factuelles telles que le délai de production (Lead Time), ou la durée d’ « en cours » d’un élément de travail (du début à la fin). Nous enregistrons cette mesure pour chaque tâche ayant traversé le processus pour nous aider à dessiner un histogramme des délais de production.

Histogramme

Mais pourquoi utiliser le délai de production d’une tâche plutôt que son temps de travail (ou « temps en main »), qui correspond à ce pour quoi le client paie (le temps durant lequel le produit requiert vraiment du travail et de la valeur est ajoutée)? Les deux métriques sont intéressantes, surtout si on les compare. Il est vrai que le client paie pour le « temps en main »… mais il doit par ailleurs attendre la durée du délai de production! Et si je me place du point de vue du client, si je demande combien de temps cela va prendre, je veux savoir combien de temps je vais attendre, pas combien de temps vous y travaillerez!

Nous pouvons maintenant penser à l’histogramme des délais de production comme à un aperçu du comportement de notre système Kanban. Nous pouvons prévoir que tout futur travail de l’équipe sera similaire à ce qui a été effectué auparavant et devrait concorder avec cet aperçu. Il demeure un certain niveau de risque que parfois la livraison d’un élément particulier requiert exceptionnellement plus de temps. À terme, lorsque nous disposons de suffisamment de données historiques pour être prévisibles, nous pouvons utiliser nos indicateurs de délais de production pour négocier un accord de niveau de service (SLA) avec nos clients (ou demandeurs).

Cela fonctionne bien pour les opérations, mais qu’en est-il des projets? L’idée est la même et la grande différence avec un projet est que nous avons probablement un plus grand carnet de tâches prédéterminées en attente. Nous pouvons toujours utiliser nos indicateurs de délais de production pour déterminer combien de temps il faudra au maximum pour fournir une fonctionnalité spécifique. En fonction du nombre de tâches prioritaires qui se trouvent dans le carnet de commandes, nous pouvons déterminer le temps nécessaire pour commencer à travailler sur cette tâche particulière. Si ce délai est inacceptable pour le demandeur, nous avons la possibilité de modifier nos priorités et de commencer ce travail plus tôt.

Le secret pour comprendre Kanban

Comme mentionné précédemment, la méthode Kanban s’est inspirée des systèmes Kanban  « tirés » utilisés dans la production Lean. Mais comment pouvons-nous appliquer des principes manufacturiers au développement de logiciels et nous attendre à une amélioration?

Tout comme dans une usine de fabrication, nous voulons réduire la quantité des stocks, ou plutôt la quantité des stocks qui ne bouge pas. Toute pièce requise pour assembler un produit fini qui ne bouge pas, est bloquée ou en attente dans le système, ne crée pas de valeur pour le client.

Lorsque vous travaillez dans le développement de logiciels ou dans tout autre type de travail de connaissance, pour comprendre les pratiques Lean et Kanban vous devez considérer que votre inventaire est en fait votre travail en cours (WIP). Réduire votre WIP est la même chose que la réduction des stocks, le déblocage de vos tâches en cours est identique au déplacement des stocks bloqués, la livraison de votre travail est identique à la livraison des marchandises. Lorsque vous réduisez votre WIP, vous réduisez la taille de vos lots. Par conséquent, vous livrerez plus souvent et aurez un retour sur l’investissement plus rapide.

Découvrez les cours Kanban offerts par Pyxis et accrédités par la Lean Kanban University

Savoir Agile

Billet précédent

Ce n’est pas Agile, c’est Lean…

Billet suivant

Les héros sont parmi nous

Pas de commentaire

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.