Cet article fait partie d’une série intitulée « Il était une fois un projet IT en Kanban », débutée en 2013 et décrivant les différentes étapes de l’accompagnement d’un grand groupe vers une transformation Agile à grande échelle, basée sur la mise en place d’un Système Kanban.
Les épisodes précédents :
- Il était une fois un projet IT en Kanban (Episode 1) : Du Story Mapping au Kanban) ;
- Il était une fois un projet IT en Kanban (Episode 2 – Part I) : Indicateurs Graphiques ;
- Il était une fois un projet IT en Kanban (Episode 2 – Part II) : Mesurer la performance du système avec les KPI ;
- Il était une fois un projet IT en Kanban (Episode 3) : Tenez vos promesses avec la prédictibilité;
- Il était une fois un projet IT en Kanban (Episode 4) : Améliorer la qualité de vos Stories ;
- Il était une fois un projet IT en Kanban (Episode 5 – Partie I) : Gérer les obstacles – La fiche Kaizen ;
- Il était une fois un projet IT en Kanban (Episode 5 – Partie II) : Gérer les obstacles – Le Kata
Cet article est la troisième partie du cinquième épisode, portant sur le suivi et la gestion des obstacles, perturbant l’efficience d’un Système Kanban.
Le premier et le second épisode ont décrit la façon dont les obstacles sont identifiés et gérés, au sein de notre Système Kanban, via la « Fiche Kaizen » et la cérémonie du « Kata ».
Nous allons maintenant décrire la façon dont l’obstacle va être analysé, de manière plus approfondie, afin d’en identifier les causes racines.
Cette étude se fait alors via une pratique nommée le A3 Problem Solving.
Cet article a été écrit en collaboration avec Clément Rochas.
Agile Mouse 