Agilité et techniques de résolution de problème

Les problèmes arrivent. C’est là une règle de base de notre métier. Parfois ces problèmes sont faciles à résoudre, mais d’autres fois, il est nécessaire de mettre en place une stratégie spécifique pour trouver une solution efficace. Ces techniques, connues sous le nom de processus de « problem solving », sont des méthodologies structurées, pragmatiques et basées sur les faits. L’objectif n’est bien évidemment pas de trouver des coupables, mais d’augmenter la qualité de notre travail, et de ce fait, ces techniques sont très souvent utilisées dans les cérémonies d’amélioration continue chères à l’Agilité.  

Trouver les problèmes

Avant de pouvoir résoudre les problèmes, il est un point capital à ne pas oublier : il faut commencer par les identifier ! Les problèmes peuvent apparaître à n’importe quel moment, et le plus tôt ils seront détectés, le plus faible sera leur impact.

En tant que manager,  il y a plusieurs moments particulièrement adaptés pour détecter les problèmes : les morning meetings et les rétrospectives. En tant que membre de l’équipe, n’attendez pas ! Si vous subissez un problème, il n’y a aucune raison d’attendre la prochaine rétrospective pour en parler, ou pire encore, de l’oublier. Il est de votre devoir de le relever le plus tôt possible. Là encore, le morning meeting peut être le bon moment pour exposer le souci. Quoiqu’il en soit, rappelez-vous que le morning meeting n’est pas le bon moment pour résoudre les problèmes.

Pour la plupart des problèmes remontés, il ne sera pas nécessaire d’utiliser une technique particulière. Une simple petite réunion avec les deux ou trois personnes concernées juste après le morning meeting sera suffisamment efficace pour les résoudre. Mais pour les problèmes réellement complexes, l’utilisation d’un process spécifique, que ce soit durant une rétrospective ou une réunion dédiée, s’avèrera des plus efficaces.

Pour être certain de résoudre un problème de manière pérenne, il faut commencer par le définir de la manière la plus précise possible. Il faut se montrer le plus spécifique possible, en donnant autant de détails que nécessaire, tant sur le problème en question (ce qui sera important pour le résoudre) que sur ses conséquences (ce qui sera important pour prioriser la résolution du problème, par rapport à toutes les autres tâches qui nous incombent). Il est aussi nécessaire de déterminer finement les critères de succès, c’est à dire les conditions qui permettent de déterminer à quel moment le problème est résolu, et donc à quel moment il est possible d’arrêter de travailler dessus.

Enfin, rappelons-le à nouveau : la découverte de problèmes et leur résolution sont des éléments naturels de notre travail. Et résoudre un problème peut en révéler de nouveaux, qui étaient cachés dans un premier temps. Mais là encore, tout cela est normal dans un processus d’amélioration continue.

Comment résoudre les problèmes

Voici maintenant une présentation rapide d’un certain nombre de techniques pouvant aider à préciser et/ou à résoudre les problèmes.

Les 5 pourquoi

Pour définitivement résoudre un problème, il faut être certain d’avoir résolu sa cause originale (on parlera de cause racine). Souvent, le problème que nous observons est juste la conséquence d’un autre problème. Dans ce cas, résoudre le problème détecté ne sera donc qu’une solution temporaire, car il réapparaîtra forcément tôt ou tard. Pour éviter cette récurrence, il  faut trouver la cause racine et la résoudre, de la même manière qu’en médecine on doit soigner la maladie, et pas seulement ses symptômes.

La méthode des 5 pourquoi vise donc à trouver cette cause racine, avec pour objectif de la faire disparaitre et par là même de faire disparaitre définitivement le problème original. Cette méthode nous demande donc simplement de poser la question “pourquoi ?” pour comprendre la raison de la survenue d’un problème. Une fois que cette première cause est trouvée, la question à se poser maintenant est “pourquoi cette cause est-elle arrivée ?”. Et on continue sur le même principe. Après 5 étapes, on a généralement découvert notre cause racine, sous réserve que les questions soient posées de la manière la plus précise possible. Une fois que cette cause racine est trouvée, on peut ensuite utiliser une des méthodes présentées plus loin, telles que le brainstorming ou les 6 chapeaux, pour la faire définitivement disparaitre.

Le diagramme d’Ishikawa

Le diagramme d’Ishikawa (aussi connu sous le nom de diagramme en arrête de poisson, fishbone diagram en anglais) est une manière visuelle d’exposer clairement toutes les causes et tous les effets d’un problème donné. L’objectif d’un tel diagramme est, en sus, de classer ces causes et effets par type et par importance. L’idée, outre de nous aider à prioriser nos actions, est de faire apparaître d’éventuelles relations entre les différentes variables de notre problème.

Des exemples de catégories pouvant être utilisées dans un tel diagramme :

• Rôles ou services (que l’on privilégiera aux personnes)
• Processus et procédures
• Matériel
• Technologie et produits
• Compétences

Brainstorming

Tout le monde pense savoir plus ou moins ce qu’est un brainstorming. Néanmoins, au delà des idées reçues, il s’agit d’un processus de résolution de problèmes précisément définis. En effet, le brainstorming est une technique visant à rassembler un maximum d’idées à propos d’un problème. L’idée majeure derrière cette procédure est que plus le nombre d’idées exprimées, ainsi que leur variété, est grand, plus nous avons de chances de trouver des réponses efficaces.

Une session de brainstorming prendra donc la forme d’une réunion (qui peut être tout ou partie d’une rétrospective Agile, comme prendre la forme d’une session de travail distincte). L’animateur de la session devra tout d’abord s’assurer que le problème est décrit de manière suffisamment précise, et pour ce faire, il pourra par exemple utiliser les 5 pourquoi ou un diagramme d’Ishikawa, tel que décrit précédemment. Ensuite, il faut choisir soigneusement les participants de la réunion. On conviera bien évidemment les membres de l’équipe qui sont concernés par le problème, mais on pourra aussi embarquer des personnes non directement liées au problème, mais ayant une bonne connaissance du contexte, des technologies concernées, ou encore qui ont déjà rencontré un problème similaire. L’idée est, comme on l’a vu, de maximiser le nombre de remarques pertinentes d’où pourra émerger la solution. Attention toutefois, comme toute réunion, à trop convier de participants, on risque de perdre en efficacité tout en augmentant sensiblement la durée, on se limitera donc à 8 ou 10 participants grand maximum.

La réunion est divisée en trois parties distinctes. Chacune de ces parties doit être limitée dans le temps. La durée totale de la réunion devrait se situer entre une demi-heure et une heure, suivant la complexité du problème. Travailler sur un temps limité est important, cela permet de maximiser la concentration des participants en évitant les digressions et la fatigue qu’une trop longue réunion engendrerait à coup sûr.
Première partie. L’organisateur présente le problème, en donnant un maximum d’informations dessus (causes connues, conséquences constatées ou anticipées, critères de succès envisageables… ). Il répondra ensuite à toutes les questions restantes, dans le but de clarifier le problème au maximum.
Deuxième partie. Nous sommes maintenant au coeur du process. Chaque personne va pouvoir s’exprimer, suggérant le nombre maximum de solutions. L’idée derrière cette étape est qu’il n’y a pas de suggestion idiote ou inutile. Une solution énoncée par quelqu’un va pouvoir aider quelqu’un d’autre à proposer une autre solution, en approfondissant, par association d’idées, par opposition… De plus, deux solutions proposées par des personnes différentes peuvent parfois être combinées pour aboutir à une troisième solution. Durant cette partie, l’organisateur de la réunion doit s’assurer que tout le monde s’exprime. Il peut ainsi multiplier les tours de table, ou encore organiser une saisie simultanée des idées sur des post-its pour ensuite les collecter et les présenter. Il doit garder trace de l’ensemble des idées exprimées (il pourra par exemple les reformuler au moment de les noter pour s’assurer de la bonne compréhension de ces dernières). Il doit s’assurer de garder un rythme soutenu et ne jamais hésiter à poser des questions pour relancer une discussion mourante, ou à interroger les personnes timides. Le but de cette partie est, rappelons-le, de laisser émerger un maximum d’idées. Mais attention, il n’est pas encore temps, à ce stade, de les discuter ou de les contester, ce qui pourrait avoir un effet inhibant.
Troisième partie. Dans cette partie, l’organisateur va récapituler formellement les idées exprimées lors de l’étape précédente. Pour plus de clarté, il pourra regrouper ensemble les idées similaires, en utilisant par exemple un tableau ou des cartes pour les présenter aux différents participants. Ensuite, les participants choisissent la solution à implémenter. Ce choix peut être fait de plusieurs manières : par vote (et là encore, on peut envisager différentes méthodes : mains levées, plusieurs jetons de vote par personne… ) ou par discussion pour laisser un consensus émerger. Plus le nombre de participants est élevé, plus la solution du vote devrait être utilisée, le consensus pouvant alors se montrer compliqué à atteindre.

La méthode des 6 chapeaux

Cette méthode classe le comportement des participants à une réunion en 6 états distincts, chacun symbolisé par une couleur différente.

• Blanc : les faits et les informations. Les participants vont discuter des faits. Les informations clés qui représentent le point d’entrée de la réunion vont être exposées et débattues. L’absence d’une information capitale ou nécessaire peut aussi être identifiée lors de cette étape.
• Rouge : le ressenti et les émotions. Les participants font état de leurs sentiments vis à vis du problème, en utilisant leur instinct. Cet état peut être utilisé pour réduire la liste des items trouvés lors des 5 autres états. On pourra par exemple organiser un vote pour que les participants choisissent ce qui, suivant leur opinion, leur semble le plus important. Cet état peut aussi être utilisé pour exprimer des opinions esthétiques, sur une interface graphique par exemple.
• Noir : les critiques négatives. Les participants regardent les problèmes, les erreurs, les freins, les barrières et les risques. Lors de cet état, on exprime toutes les gênes, on ne cherche pas à les résoudre.
• Jaune : être positif et optimiste. Les participants identifient les bénéfices pouvant être associés aux différentes idées exprimées. Ces bénéfices doivent être trouvés de manière analytique et justifiée, il ne s’agit pas d’un “optimisme aveugle” qui aurait plus sa place lors de l’état rouge. L’objectif est de trouver des réflexions argumentées en faveur des idées exposées.
• Vert : les idées nouvelles. Les participants expriment, de manière ouverte, de nouvelles idées, sans essayer de les défendre ou de les combattre (ce qui correspond aux états jaune et noir). Cet état est similaire à la deuxième étape du brainstorming que nous avons vue précédemment.
• Bleu : la méta réflexion. Dans cette partie, les participants peuvent discuter du process de résolution de problèmes lui-même, dans le but de l’améliorer. C’est un état très utile en début de réunion pour se mettre d’accord sur les règles du jeu, ou en fin de réunion pour chercher à améliorer notre process. Utilisé en plein milieu, par contre, cet état peut fortement en perturber le cours.

Pour maximiser l’efficacité de votre réunion, vous devez vous assurer que les participants échangent ensemble, à un instant donné, avec le même état d’esprit. Une personne dans un état d’esprit blanc, c’est à dire exposant de simple fait, aura par exemple du mal à se faire comprendre d’une personne dans un état d’esprit rouge, c’est à dire en plein dans le ressenti. Cependant, dans une démarche de résolution de problème, chacun de ces états d’esprit a quelque chose à apporter. En utilisant la technique des 6 chapeaux, l’animateur de la réunion porte métaphoriquement un chapeau d’une couleur donnée pour orienter les débats vers un certain état d’esprit, avant de passer à un chapeau, tout aussi métaphorique, d’une autre couleur, pour relancer la discussion. Rien ne vous empêche cependant de porter de véritables chapeaux colorés lors de vos réunions.

L’efficacité de cette méthode va totalement dépendre du choix judicieux de la séquence des différentes couleurs, et de la capacité de l’animateur de maintenir les participants dans le bon état d’esprit (et en particulier, éviter la résurgence de l’état d’esprit noir lorsqu’il n’est pas approprié).

PDCA

PDCA (pour Plan Do Check Act) est une méthode itérative et scientifique de résolution de problème. Les différentes étapes d’une itération sont :

• Planifier : considérer l’état actuel, identifier la ou les causes racines, établir des objectifs chiffrés en tant que critères de succès, mettre en place les outils permettant de mesurer les améliorations. Enfin, créer un plan d’action, avec une date de fin.
• Faire : dérouler le plan d’action, ou éventuellement uniquement une partie de celui-ci. Effectuer les mesures prévues pour vérifier les éventuels progrès.
• Vérifier : mesurer les performances du nouveau process, et les comparer d’une part à notre état de départ, et d’autre part à notre état final espéré.
• Acter : si l’état espéré et l’état obtenu sont les mêmes, le nouveau processus devient une nouvelle norme de notre projet. Si ce n’est pas le cas, on analyse la différence entre ces deux états, et on essaie d’en trouver la cause racine. Cette cause racine pourra être notre état de départ pour une nouvelle itération du cycle PDCA.

Principe de Pareto (règle des 80 / 20)

Le principe de Pareto (nommé d’après l’économiste Italien Vilfredo Pareto) part du principe que, dans une population suffisamment large, 80% des effets proviennent de 20% des causes. Par exemple, dans un contexte informatique, on peut dire que 80% des demandes viennent de 20% des clients. Ou encore que 80% de la valeur d’une application vient de 20% des fonctionnalités.

Ce principe peut être très intéressant dans un contexte de résolution de problème (par exemple dans l’optique de l’optimisation des performances d’un système). Il faut en effet identifier, et se concentrer sur les 20% des causes qui sont les plus impactantes en premier. Et c’est d’autant plus vrai dans un contexte à ressources limitées. Il est généralement beaucoup trop cher (en temps, en ressources ou en argent) de résoudre l’intégralité des causes de notre problème. Il est souvent suffisant de se concentrer sur les 20% des causes qui comptent vraiment.

Pour résumer, une fois que vous avez identifié les causes racines de votre problème, vous devez toujours rechercher celles qui sont vraiment importantes, dans l’optique de prioriser vos actions pour vous concentrer sur ce qui apporte réellement de la valeur à votre démarche de résolution de problème.

En conclusion

Les problèmes vont arriver, c’est un fait, on n’y échappera pas. Mais nous ne sommes pas forcément livrés à nous-même pour les affronter, nous disposons d’une boîte à outils extrêmement fournie pour les affronter, proposant pléthore de méthodes pragmatiques et scientifiques. Et ce ne sont là que quelques exemples.

Pour aller plus loin

Les 5 pourquoi
Le diagramme d’Ishikawa
Les 6 chapeaux
Le PDCA
Le principe de Pareto