Comment Kanban peut-il apporter un rythme soutenable aux équipes de support ? L'exemple du Système d'Information du Territoire

Situation et défi initial

Avez-vous parfois l'impression de constamment éteindre des feux, sans forcément savoir si ce sont les feux les plus urgents et les plus importants que vous éteignez ? Ou si éteindre les feux est vraiment le plus important ? Un tel fonctionnement est certes gratifiant de par son aspect héroïque, mais mène vite à la fatigue et la frustration. Heureusement, il est possible de "sortir la tête du casque ignifuge" et de prendre de la hauteur grâce aux approches Agiles, dont Kanban fait partie. Découvrez comment l'équipe du Système d'Information du Territoire (SIT) de la ville d'Yverdon-les-Bains en a tiré parti pour améliorer l'organisation de son travail.

Kanban à la rescousse

La Méthode Kanban (du japonais "kanban" qui signifie "carte que l'on peut voir") a été développée chez Microsoft dans les années 2000, en s'inspirant notamment des systèmes mis en place sur les chaînes de production Toyota dans les années 60.

Kanban c'est un ensemble de principes, de valeurs et de pratiques visant à optimiser un flux de travail. Un flux de travail, mais pas n'importe lequel: on parle de "flux tiré", et c'est déjà un grand changement de paradigme pour de nombreuses équipes. Lorsque l'on travaille à "flux tiré", c'est l'équipe qui, lorsque de la capacité se libère, “tire” du lot de demandes en attente la demande la plus importante à ce moment-là, au lieu que ce soit les parties prenantes qui "poussent" le travail dans le système de l'équipe, comme c'est souvent le cas !

Un autre pilier de la méthode Kanban est d'employer un système visuel, afin d'apporter à tous la transparence totale sur l'état du système et les règles régissant le travail de l'équipe. Enfin, il est nécessaire de poser des limites sur la quantité de travail en parallèle, quitte à les dépasser momentanément, mais en étant conscient que cela révèle un dysfonctionnement du système.

Voilà un programme bien ambitieux, me direz-vous. Les auteurs de la méthode en sont pleinement conscients et proposent, plutôt qu'une transformation "big bang", de "partir de là où l'on est". C'est-à-dire de commencer avec le système actuel, tout imparfait soit-il, et de lancer un moteur d'amélioration continue à partir de là. Voilà qui rend la tâche plus accessible et c'est dans cet état d'esprit que j'ai rendu visite à l'équipe du SIT.

Ce qui a été mis en place

La première étape a été de représenter tous les états du système actuel sous forme d'un tableau Kanban. Tous les états, par exemple "Demande réceptionnée", "Demande en traitement"... y compris les entre-deux pas très clairs dans lesquels une tâche peut se trouver coincée. Ça vous rappelle quelque chose ?

L'étape suivante a été de poser une limite initiale sur les différents états intermédiaires de traitement d'une tâche. En effet, c'est un grand classique, travailler sur trop de choses en parallèle (le fameux "Work In Progress" ou WIP) décroît spectaculairement l'efficacité.

Ensuite, nous avons parlé de la façon dont les demandes sont formulées et avons abordé le format User Story, qui permet une compréhension commune du "pourquoi" entre le demandeur et l'équipe. Ainsi, il est possible d'effectuer une meilleure priorisation et des propositions de solutions souvent plus pertinentes que ce que le demandeur avait imaginé au départ.

Une fois ceci fait, nous avons documenté et affiché toutes les "règles du jeu" appliquées jusqu'ici tacitement par l'équipe dans le processus de traitement d'une demande. Par exemple, comment définit-on la priorité ? Qu'est-ce qui fait objectivement qu'une demande est prête pour implémentation ou qu'elle a bien été traitée ?

Jusqu'ici, un travail somme toute assez scolaire. La toute dernière étape a été de lancer ce qui fera le succès ou non de cette transformation. Il s'agit du moteur d'amélioration continue, bien connu dans le monde Agile. Pour cela, on planifie des séances récurrentes dites de "rétrospectives", où l'équipe se réunit pour débriefer honnêtement sur son fonctionnement pendant une période donnée. De ce moment d'introspection (mais pas d'autocritique) on tire une ou deux améliorations à apporter au système: par exemple, adapter la limite de travail en cours sur tel état ou ajouter un nouvel état intermédiaire. L'expérience des semaines suivantes dira si cette adaptation était pertinente. Et ainsi de suite. Ainsi, le système reste au service de la réalité et non l'inverse. À noter qu'il est indispensable de collecter des retours de la part de ceux à qui bénéficient les travaux réalisés en tout temps !

Le résultat après un mois

Petit à petit les résultats se font ressentir. Les demandes sont mieux structurées, grâce au formalisme apporté par les User Story. La visualisation sous forme de tableau offre une vue d'ensemble des demandes, et apporte la transparence aux parties prenantes extérieures à l'équipe. Rendre visible l'avancement du travail est également une source de motivation. Enfin, les étapes explicites qui précédent l'implémentation (analyse et validation par le demandeur) assurent qu'un accord sur le travail à faire a été atteint.

Une amélioration continue

Suite à la première rétrospective, les actions concrètes sont prises pour faciliter la saisie de demandes pour les utilisateurs du SIT, ainsi que pour rendre plus aisé la consultation par tous du tableau Kanban et des règles de fonctionnement. Lorsque ces dernières sont enfreintes, l'équipe s'engage à documenter les cas afin de décider des adaptations les plus pertinentes. Le tableau physique est remplacé par un équivalent numérique afin de s'adapter au travail à distance.

La collaboration avec Liip

Au départ une collaboration purement technique, les échanges entre le SIT et Liip ont suscité une réflexion particulièrement enrichissante autour de l'organisation du travail dans un contexte de changement permanent.

La capacité de Liip à comprendre le contexte d'intervention et ses spécificités s'est révélée un atout déterminant dans la réussite de cette mission.