Visualisez vos problèmes !
Cet article est l’œuvre d’un blogeur invité: Alan Hortz. Voir en fin d’article pour de plus amples informations.
Le Problem Log, à priori ce nom peut sembler familier à une personne ayant déjà travaillé dans le milieu de l’informatique, une telle personne peut s’imaginer d’emblée un fichier informatique au format texte avec beaucoup d’informations, telles que l’heure, une description précise du problème, l’endroit exact dans le programme informatique ou le problème est survenu. En bref un gros fichier rempli d’information et finalement assez difficile à comprendre.
C’est précisément l’image qui m’est venue à l’esprit lorsque Bruno Sbille m’a parlé pour la première fois du Problem Log, une petite dizaine de questions plus tard, la définition du Problem log avait pris une tout autre forme, celle d’un fichier Excel avec deux colonnes, un descriptif du problème rencontré et un statut, le problème est réglé ou ne l’est pas.
Fort de cette définition, j’ai donc créé un fichier Excel en quelques clics de souris et le tour était joué. Et ensuite? Voilà exactement la question que j’ai posée à Bruno après avoir fièrement sauvegardé le fameux fichier. Bruno m’expliqua que le rôle du Scrum Master est entre autres de faire en sorte que l’équipe progresse le mieux possible en rencontrant le moins d’obstacles possible et que tous les problèmes rencontrés par l’équipe ou par le Scrum Master lui-même devaient y être consigné.
Le jour suivant, durant le « Daily Meeting », j’écoutais attentivement, je concentrais mon attention sur les paroles prononcées par les membres de l’équipe, j’attendais impatiemment que le mot « problème » soit prononcé pour enfin pouvoir alimenter ce merveilleux fichier qui allait résoudre tous les problèmes de productivité, en tout cas je le pensais. Ce mot clé n’était pratiquement jamais prononcé par les membres de l’équipe, et lorsqu’il l’était il était toujours accompagné d’un adjectif qualifiant le problème de mineur ou de simple à résoudre, parfois même lorsqu’un problème était évoqué par un membre d’équipe il était aussitôt rediscuté par un intervenant externe qui annulait le caractère problématique du sujet discuté en moins de dix secondes.
J’allais vite comprendre que derrière le discours d’une personne se cache bien des choses, tout d’abord, il y a le ressentit de la personne au moment ou elle parle publiquement, ensuite, il y a le vocabulaire employé et l’intonation de sa voix, enfin la gestuelle qui accompagne le discours est tout aussi importante.
Un acteur connu a dit en son temps « Il faut être aware », je comprends un peu mieux ce que ce brave homme voulait dire, c’est donc après avoir travaillé mon écoute, au sens large, que j’ai été confronté à une autre difficulté, la résolution des problèmes. Et oui, l’un ne va pas sans l’autre, des problèmes surviennent, il est nécessaire de les résoudre, ou tout du moins mettre en place des actions concrètes destinées à atténuer les impacts négatifs de ceux-ci.
Qu’est-ce qu’un problème finalement, une simple ligne dans un fichier Excel lui-même logé bien au chaud dans une généalogie de dossiers aux noms peu évocateurs ? Je suis arrivé à une conclusion personnelle, pour résoudre efficacement un problème qui survient dans une équipe, il doit être compris de tous et être présent à l’esprit de tous jusqu’à ce qu’une solution acceptable soit trouvée. Fort de cette conclusion, il me fallait trouver un moyen pour atteindre cet objectif, c’est alors que je me suis souvenu des sages paroles de Bruno, « Toujours mettre en place la solution la plus simple et adapter ensuite ».
Afin de mettre en place une solution qui amène de la visibilité auprès de l’équipe et des chalands, j’ai utilisé un flipchart (ou paperboard), c’est un outil facile à déplacer et en général il est toujours possible d’adapter sa hauteur. Une seule feuille est utilisée, une seule ligne délimite la feuille en deux colonnes. Deux libellés de colonnes ont été inscrits, la première colonne libellée « Open » contient les points bloquants et les problèmes qui sont découverts, la deuxième colonne libellée « Closed » contient les éléments qui ont été résolus.
À la fin de chaque daily stand-up, je résume les problèmes « entendus », je les note sur un post-it et je les place dans la colonne OPEN, je résume les avancées faites sur les autres post-its existants de cette colonne et déplace ceux qui ont été résolus dans la colonne CLOSED.
Le fichier Excel est toujours utilisé pour conserver à un seul et même endroit les problèmes rencontrés, en effet à la fin de chaque sprint la feuille est débarrassée des problèmes réglés.
Cette solution est en place depuis quelques mois, au cours des derniers sprints, les membres de l’équipe eux-mêmes prenaient le soin de placer les problèmes rencontrés dans la colonne OPEN et de mettre à jour le statut des problèmes résolus.
Toute l’attention doit être mise sur les éléments qui empêchent l’équipe d’être efficace et il est important de faire vivre ce flipchart en faisant régulièrement le point avec l’équipe et les parties prenantes.
L’exercice qui consiste à identifier les problèmes au sein d’une équipe n’est pas évident de premier abord, il se pratique à tous les moments de la journée, il faut être attentif aux comportements et discussions sur le plateau afin de déceler les problèmes et mieux définir les conditions dans lesquelles ils se posent.
Alan Hortz.
A propos de l’auteur:
Alan est actuellement Scrum Master pour la société Ogone. Ogone est un acteur spécialisé dans les services de paiement électronique.
En plus de ses 9 années d’expérience dans le monde IT, il termine actuellement un master en informatique aux facultés universitaires Notre Dame de la Paix à Namur.
Alan est passionné par l’informatique depuis que ses doigts se sont posés sur le clavier d’un Commodore 64. Depuis sa curiosité l’a amené à explorer les différentes techniques de développement logiciel tel que le unit testing, le développement mobile, l’intégration continue et récemment Scrum et d’autres méthodes Agile.
Photo: Virginie Sbille.
