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.
Un des principes inscrit dans le manifeste agile dit qu’un logiciel opérationnel sera préféré à une documentation exhaustive. De même dans la résolution de problème on préfèrera éviter les documents rédigés qui complexifient le processus de compréhension et les chances de résoudre le problème.
Le but du rapport A3 est de synthétiser un problème et de l’énoncer clairement. Il favorise la communication verticale. Par exemple, il va permettre à l’équipe de rassembler sur une page toutes les informations qui permettront de présenter à la hiérarchie les faits et les raisons d’un point bloquant la productivité.
Historique & apports du A3
Il n’y a pas d’inventeur connu du rapport A3, il est né de la volonté d’appliquer la méthode de gestion de la qualité dite PDCA (Plan, Do, Check, Act). L’histoire veut que Taiichi Ohno, le père du système de production de Toyota connu également sous le nom de toyotisme, refusait de lire plus de la première page des rapports.
Le A3 permet aux personnes de collaborer pour résoudre des problèmes. En japonais Nemawashi, qui désigne un processus informel permettant de préparer en douceur un changement important.
Il y a de nombreux avantages à utiliser ce format :
- La relecture des parties déjà achevées permet de se concentrer plus facilement sur l’étape en cours ;
- En avançant sur la réflexion, il est possible de contenir la taille du document grâce au format contraint ;
- Un nouvel intervenant comprend rapidement le sujet et peut rapidement contribuer à la solution.
Chez Toyota, il y a trois types de A3 :
- proposal ;
- status report ;
- problem solving
Dans notre cas, nous favorisons le A3 Problem Solving, c’est à dire un accompagnement de résolution de problème durant nos Kata, comme le 5P, 8D, etc.
Le format A3 Problem Solving
Le format papier A3 est le support qui donne son nom à cet outil. Ce format contraint est volontaire, il permet de se restreindre aux informations les plus importantes. On préféra l’utilisation du papier qui sera l’occasion de discuter autour d’une table.
Le A3 est découpé en 8 étapes qui respectent le modèle PDCA. Elles seront rédigées par différents acteurs tout au long du processus de résolution.
Le A3 pas à pas
Identifier les causes racines est une des étapes majeures de la démarche.
Les causes racines
Lors de l’identification d’un problème, nous avons toujours tendance à regarder la surface émergée de l’iceberg comme cause du problème. L’analyse des causes racines a pour objectif d’effectuer une analyse en profondeur, afin d’identifier l’origine d’un obstacle et de s’assurer de prendre les bonnes décisions, permettant de le résoudre au mieux.
Une des techniques d’analyse, qui a ma préférence, est celle dite des "5 pourquoi".
Les 5 pourquoi (5P)
Les 5 pourquoi fait partie de l’arsenal des systèmes de qualité et dont l’objectif est la résolution de problèmes au travers de l’identification des causes racines.
Le processus est assez simple. il s’agit de poser une suite de questions, commençant toujours par un pourquoi et portant sur la réponse à la question précédente, afin de trouver la source, cause principale de la défaillance.
Un cas concret
Sur notre projet, 14 jours après le lancement, toujours aucune story n’est Done. Cette situation a des impacts sur l’efficience de notre système Kanban, dans la mesure où un goulet d’étranglement se constitue à l’entrée de la phase de développement et que cela bloque l’activité du Product Owner et de l’équipe en charge de l’écriture des cas de test. Sans compter le risque grandissant sur l’incapacité de l’équipe à tenir ses promesses.
Je propose donc au Product Owner et au ScrumMaster de réaliser notre premier A3, après avoir pris le temps d’en expliquer le fonctionnement et les apports attendus.
Lors du cérémonial, nous suivons les étapes 1 à 3, décrites précédemment. Ces étapes nous ont permis d’indiquer à tous le problème que nous rencontrions sur le projet, l’état des lieux actuel et les objectifs recherchés.
Vient alors l’étape d’analyse des causes racines. Nous utilisons pour cela la pratique des 5 pourquoi :
- Pourquoi ne pouvez-vous pas livrer de story en phase de test ? Réponse : Nous rencontrons des problèmes avec les environnements de développement de l’équipe
- Pourquoi rencontrez-vous des problèmes avec les environnements de développement ? Réponse : Nous avons installé une nouvelle version du provider Oracle, sur les postes de travail et cela fait planter l’environnement de développement.
- Pourquoi l’installation du provider Oracle fait planter les environnements de développement ? Réponse : l’installation est faite par les développeurs, qui n’ont pas les compétences pour effectuer ce travail.
- Pourquoi l’installation est faite par les développeurs, alors qu’ils n’ont pas toutes les compétences pour cela ? Réponse : l’expert technique Oracle n’est pas disponible.
- Pourquoi l’expert n’est pas disponible ? Réponse : En fait, nous lui avons demandé de l’aide, mais il n’a pas le temps de s’occuper de nous.
L’identification de la cause racine de la défaillance de notre système nous a permis, ensuite, de proposer plusieurs scénarios de résolution et un plan d’action, associé à des métriques, qui nous ont permis de suivre l’efficience de la mise en oeuvre de ces actions.
Le résultat a été à la hauteur de nos attentes. L’expert Oracle a été dépêché en urgence, afin de mettre en place le provider Oracle, sur tous les postes, ce qui a permis de résoudre les problèmes liés aux environnements de développements. L’efficience de la résolution de cet obstacle a été associée à des objectifs, en terme de débit de stories Done (terminée) par semaine et de réduction du temps de réalisation des dites stories. Objectifs que l’équipe a atteints et même dépassés.
Mise en oeuvre
Le A3 est réalisé lors d’un cérémonial, nommé "Kata", dont le processus a été décrit dans la seconde partie de cet épisode : Il était une fois un projet IT en Kanban (Episode 5 – Partie II) : Gérer les obstacles – Le Kata.
Take Away (aller plus loin)
Le A3 comme outil pour fluidifier la rétrospective
Si un problème critique est remonté par l’équipe et que visiblement aucune solution n’est envisageable au niveau des personnes présentes dans l’assemblée, le problème risque de ne pas trouver de solution et d’échauffer les esprits. L’initiation de ce rapport A3 ainsi que la création d’un binôme ou d’un petit groupe en charge d’identifier le besoin sera un geste fort. Il permettra de déterminer l’action qui va amorcer l’amélioration. L’équipe pourra alors se concentrer sur les autres points importants de la rétrospective. Une action aura été définie et, lors de la rétrospective suivante, un constat sur l’évolution sera fait.
Pour régler un problème qui n’a trouvé aucune solution dans l’équipe, il nécessaire de préparer sa mise en lumière. Si la seule personne qui a le pouvoir de faire quelque chose est votre N+3, il va falloir lui vendre votre histoire. Il faudra lui avancer du concret, des indicateurs, une vision des bénéfices de résolution. C’est un cas de communication organisationnelle dite verticale ascendante.
Je conseille à tout scrummaster de partir en rétrospective avec un template de rapport A3. Attention! Si le problème nécessite d’initier une fiche, c’est que ses causes profondes ne sont sans doute pas si simples et trouver une solution envisageable (coût, délais de mise en place, etc.) ne sera peut-être pas possible. Dans tous les cas la vision du problème devrait être améliorée et la réflexion pourra être publiée sur un wiki, par exemple.
Récemment lors d’un atelier j’ai entendu l’un des intervenants dire qu’il avait proposé une solution il y a plus d’un an et qu’il n’avait plus eu de nouvelle. Si le A3 avait était formulé et publié sur le réseau de l’entreprise, la roadmap aurait été visible et le problème serait peut être déjà résolu.
Ressources
Top 5 reasons to celebrate mistakes at work
Use A3 technique to solve serious problems
Pour aller plus loin sur les différents types de A3 : http://www.beyondlean.com/support-files/a3-reports.pdf