Il y a 4 années · 9 minutes · Agile

Il était une fois un projet IT en Kanban (Episode 5 – Partie III) : Gérer les obstacles – Le A3 Problem Solving

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.

Cette série comporte les épisodes suivants :

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. Nous allons y 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.

kanban

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.

kanban

Le A3 pas à pas

kanban

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 :

  1. 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
  2. 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.
  3. 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.
  4. 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.
  5. 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

La Roue de Deming

Top 5 reasons to celebrate mistakes at work

Template A3

A3 thinking

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

Couthaïer Farfra
18 années d’expériences, dont 14 années en pilotage et direction de projets Mainframe et NTIC (Forfait, Assistance Technique, TMA, Centre de Services). Depuis 2009, j'ai découvert avec enthousiasme le monde de l'agilité, au travers de la réalisation de projets IT Scrum ou je suis intervenu en tant que Scrum Master et Consultant Agile (Crédit Agricole S.A., GENERALI, Banque de France, CNSA). En 2012, j'ai rejoins la société XEBIA ou j'interviens en tant que Consultant et Formateur (BI-SAM ; Voyage SNCF.com ; SFR ; Française Des Jeux ; Europcar ; AXA) sur les pratiques Agile et plus particulièrement le Kanban.
Clément Rochas
Coach agile, formateur DevOps, speaker. Clément est passionné par le développement et la création logicielle en général. Retrouvez Clément sur twitter sur @crochas
Xebia France
Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 11 ans nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Laisser un commentaire

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