Kanban pour l’IT de Laurent Morisseau

Le Kanban est une autre des grandes méthodes de la famille Agile, et à y regarder de près elle gagnerait à être plus connue.

Le Kanban est issu à l’origine de la méthode mise en place chez Toyota qui vise à optimiser le temps entre la commande du client et la livraison effective du produit et donc le paiement.

Pour cela, on va faire en sorte que chaque activité maximise le temps passé à ajouter de la valeur au produit tout en diminuant ou supprimant les activités n’apportant pas de valeur.

D’abord inventé dans l’automobile il est aussi possible d’adapter le kanban à la création de logiciel.

Parmi ses avantages il y a celui de pouvoir démarrer là où en est l’équipe dans sa maturité de connaissance des processus.

Pas besoin de faire tout de suite une révolution culturelle pour démarrer comme l’exige Scrum,
on peut garder les mêmes personnes et les mêmes rôles. L’équipe ajoutera au fur à mesure de son cheminement et de sa maturation les éléments de la méthode afin de s’améliorer continuellement.

Ce peut être aussi une solution pour les équipes n’arrivant pas à passer à Scrum pour des raisons culturelles d’entreprise mais voulant tout de même être plus agiles.

La méthode

Le kanban n’a pas de règles imposées mais 5 pratiques conseillées:

• Visualiser les éléments de travail et les processus
• Limiter le travail en cours
• Gérer le flux de travail par la capacité disponible
• Rendre explicite les règles de gestion du processus
• S’améliorer de façon collective

Contrairement aux autres méthodes logicielles où la force d’avancement va de l’amont vers l’aval (ex: on produit d’abord les éléments logiciels puis on teste ce que l’on a produit quitte à produire des files d’atttente chez les testeurs) on utilise ici le “flux tiré”, c’est la demande du client ou la disponibilité d’une capacité aval qui va déclencher la mise en route du travail amont. (ex: on ne va pas développer de nouvelles fonctionnalités si l’équipe de test en fin de projet est saturée et ne peut plus accepter de nouvelles fonctionnalités à tester.)

Cette approche qui peut sembler contre productive à première vue (car elle n’impose pas une occupation à 100% de l’équipe) a plusieurs avantages:

• On maximise la vitesse de traversée des éléments de travail => moins de file d’attente de fonctionnalité en attente
• Moins de file d’attente = moins de stock = moins de risques de découvrir des bugs trop tard ou pire avoir le même bug dans tous les éléments de la file d’attente. (Cela est encore plus vrai dans l’industrie de production. Si une pièce de voiture présente un défaut il vaut mieux le savoir le plus vite possible et éviter d’avoir produit trop de voitures à reprendre)

Le livre

Le livre de Laurent Morisseau, qui m’a été conseillé par mon collègue agiliste Alfred Almendra, explique en détails ce que peut être le kanban pour l’IT.

Après avoir rappelé l’origine industrielle de la méthode, puis présenté son positionnement
parmi les autres méthodes existantes, il présente dans une première partie les fondements de la méthode:

• Les 5 pratiques conseillées mais non obligatoires,
• l’intérêt d’un management visuel,
• le cycle PDSA (Plan Do Study Act) d’amélioration continue.

Dans une deuxième partie il revient sur les mesures et les optimisation à apporter au système pour:

• Calculer la limite haute et basse des travaux en cours et le pourquoi de ces limites
• Calculer les temps de traversée des tâches
• Corriger les blocages (voulus) du système pour l’améliorer

Enfin dans une troisième partie il détaille l’aspect viral de l’amélioration continue kanban
impactant le management et leadership de l’organisation.

Tout cela en l’illustrant avec les tribulations de plusieurs équipes migrants à leur rythme vers le kanban car partant d’origines différentes.

En effet l’une suit un management classique avec chef de projet de style commander et contrôler et cycle en V, et l’autre utilise Scrum mais cherche à être encore plus agile avec le kanban pour permettre de livrer plus souvent que la durée des sprints.

Conclusion

Ce livre est très complet et présente en détails la méthode sous toutes ses formes avec des rappels aux sous-jacents scientifiques (théorie des contraintes, théorie des files d’attentes, etc…) mais sans faire décrocher le lecteur.

Enfin au lieu de passer sous silence les problèmes auxquels vont se heurter les nouvelles équipes, il détaille, à l’aide de son expérience qui parait solide, les différentes solutions à apporter en fonction des types de problèmes rencontrés.

Un must pour tous ceux qui veulent une référence en français sur le Kanban.