La session commence par une petite introduction de Laurent et Xavier sur Kanban. Laurent nous précise que Kanban n’est pas spécifique aux développements logiciels, mais est bien un processus issu de l’industrie et notamment une mise en oeuvre opérationnelle d’une partie de Lean.
Le Kanban est un système complexe adaptatif pour favoriser les petits changements incrémentaux :
5 principes fondamentaux :
- Visualiser le processus
- Limiter le travail en cours à la capacité de l’équipe
- Mesurer et gérer le flux de travail
- Rendre les politiques du processus explicite
- S’améliorer de manière collaborative
Contrairement à Scrum qui favorise l’amélioration continue au travers de la livraison d’un incrément limitée par le timeboxing, Kanban s’oriente plus sur la gestion des états et la limitation du travail en cours pour gérer l’amélioration continue sans changer le processus et les rôles déjà mis en place.
Pour finir avec les comparaison, Scrum peut être vu comme un cas particulier du Kanban.
Laurent et Xavier insiste sur l’importance de la limitation du nombre de tâches par étapes, et sur le fait fait que Kanban fonctionne en flux tiré.
Les limites du Work In Progress sont expérimentales et l’équipe doit les choisir et les adapter.
Le Lead Time :
Le pilotage en kanban s’effectue par le Lead Time, c’est le temps que mets une tâche entre son arrivé dans le flux de travail et sa sortie du cycle. L’objectif est de déterminer le temps moyen pour réaliser le cycle nominal d’une catégorie de tâches, ce qui permet de s’engager sur un nombre de jours pour la réalisation.
Après cette introduction d’1/2 heure, il est temps de passer à la pratique. Pour ce faire, nos agilistes rennais sont venus avec 2 plateaux de jeu, ce qui nous permet de faire 2 équipes de 8 personnes et de mettre en place un concours!
La durée d’une partie est d’environ 1h30, l’objectif du jeu est de faire le plus d’argent possible en livrant les fonctionnalités d’un logiciel.
Bien évidemment, le parcours est perturbé par des impondérables, c’est à l’équipe de s’adapter et de mettre en place la stratégie qu’il faut pour respecter les contraintes associés à ceux-ci.
Régulièrement, Laurent et Xavier arrêtent le jeux pour faire une rétrospective et nous expliquer les impacts qu’ont eu les récents événements sur notre production au travers des graphiques de pilotage.
Oui, je vais répondre la question que vous vous posez tous …. Malheureusement, notre équipe perdu 
La soirée se termine par une rétrospective globale et de nombreux échanges autours de quelques pizzas.
Pour conclure, ce type d’atelier permet rapidement de comprendre les enjeux et le fonctionnement nominal de Kanban, quand en plus ils sont réalisés par 2 très bons agilistes comme le sont Laurent Morisseau et Xavier Torpe, vous ne pouvez passer qu’une bonne soirée de découverte!
Encore un grand merci à eux deux, en espérant les revoir lors du prochain AgileTour de Rouen !
Une petite précision sur la comparaison Kanban vs Scrum qui peut prêter à confusion:
La remarque sur le fait que Scrum peut être vu comme un cas particulier du Kanban se situe sur la partie cadence du Kanban:
La cadence Scrum est simple: Time-box incrémentale : à chaque fin de cycle, on livre, on démontre, on s’améliore, on planifie.
Le Kanban propose une cadence pouvant être découplée: une livraison lorsqu’une MMF est finie, une rétrospective tous les 15 jours, un planning toutes les semaines par exemple.
A ce titre, on peut avoir un système Kanban ou ces activités sont synchronisées: on retombe sur une approche Scrum, plutôt Scrum Ban.
Maintenant la cible du Kanban reste une cadence juste à temps avec une planification à la demande, une amélioration à la demande au travers des cercles de qualités, sessions Kaizen ou autres.
On peut continuer faire le jeu des similitudes et différences entre Kanban et Scrum. Il y en a qui sont fondamentales évidement, comme la cadence juste à temps. L’amélioration continue par exemple, le moteur c’est la time box pour Scrum et la limite sur les états pour le Kanban. Le processus incrémental vs en flux également. A contraintes différentes, comportements émergents différents.
@Laurent Morisseau – Merci beaucoup Laurent pour ces précisions
Pingback: Retour sur le ScrumDay | AgileIT