Des tableaux de suivi au management visuel
- Les tableaux de suivi – pourquoi ça n’a pas fonctionné
- Le management visuel – comment conduire le changement
- Le rôle du Scrum Master
Pendant 4 ans, j’ai pu suivre l’évolution de la mise en œuvre des démarches lean et agile dans un groupe bancaire. La première étape visible de ces changements a été la mise en place de « management visuel ».
J’ai observé au départ dans les bureaux, quelques timides initiatives, visibles à travers des tableaux affichés sur les grands murs. Ils appelaient ça Kanban, et je peux vous assurer aujourd’hui que ça n’en était pas. Quelques temps plus tard, j’ai constaté une progression fulgurante. Je vous partage mon point de vue.
Les tableaux de suivi – Pourquoi ça n’a pas fonctionné
Historiquement, les équipes entretenaient des relations clients-fournisseurs avec leurs partenaires (MOA-MOE) et travaillaient sur environ 4 livraisons par an. Le périmètre de livraison était préalablement chiffré par une équipe offshore puis figé avant le début des développements.
L’équipe MOE avait mis en place un tableau de suivi pour partager l’avancement de la release, en prenant soin d’identifier les étapes du processus de livraison. Elle se réunissait chaque jour pour réaliser un « Daily Meeting ». Ce fut le premier pas nécessaire pour pouvoir accompagner l’équipe à comprendre ses axes d’améliorations…
- Le besoin Métier : « c’est urgent, il faut l’intégrer dans la prochaine livraison », certains éléments ont été chiffrés et figés dans le périmètre alors que le besoin Métier n’était pas encore clair. Cela était pressenti lorsqu’il y avait une attente de spécifications, et implicitement un besoin de validation Métier. Pour autant, cette étape n’était pas visible sur le processus affiché.
Résultat : création d’attentes - Le flux poussé : l’envoi des spécifications par exemple, dépendait des personnes qui les rédigeaient, et certains attendaient d’avoir terminé tous leurs items avant de les transmettre à leur correspondant MOE. Idem pour la recette, celle-ci était effectuée pendant une phase spécifique, une fois tous les développements terminés.
Résultat : augmentation des délais - La visualisation des dysfonctionnements : les items concernant la release étaient bien affichés sur le tableau, et étaient très peu déplacés. En échangeant avec l’équipe, soit elle connaissait la cause du non-avancement, soit elle n’avait pas de visibilité dessus. Pour autant, en regardant le tableau, on ne pouvait pas se rendre compte que quelque chose n’allait pas, car les problèmes n’étaient pas affichés.
Résultat : on pense que tout va bien - Le Daily intra-équipe : l’équipe MOE se réunissait chaque jour pour échanger sur l’avancement de la release, l’équipe MOA et l’équipe de développement n’étaient pas conviées.
Résultat : impossible de suivre l’avancement du plan de release dans sa globalité. - Tout n’était pas affiché : il arrivait que les membres de l’équipe soient occupés par exemple par des incidents survenus en production, et ceux-ci n’étaient pas affichés sur leur tableau de suivi.
Résultat : charge non anticipée et mise en péril du périmètre de release - Des items ajoutés : bien que le périmètre de release était figé au départ, il se pouvait que la MOA inclut des éléments supplémentaires. L’équipe n’avait pas intégré les enjeux de la priorisation et de la négociation (exemple : on peut ajouter un élément si l’on en enlève un de même taille), et se pressait donc pour essayer d’intégrer ces nouveaux éléments.
Résultat : de la disqualité
Ce que l’on peut retenir de ce tableau de suivi, c’est qu’il ne permettait pas de piloter les activités de l’équipe, ni de donner de la visibilité aux parties prenantes par exemple. Ce fut tout de même un premier pas qui a permis l’équipe et à ceux qui l’accompagnaient d’avoir un support commun et visuel pour entreprendre des actions d’amélioration dans cette direction : « faire voir ce qui a du sens, et donner du sens à ce qui se voit » – Michel Greif, L’Usine s’affiche.
Le management visuel – comment conduire le changement
Autre contexte, autre équipe. Celle-ci a fait le choix de l’agilité et plus particulièrement de Scrum. Pour initier le management visuel, le point de départ est de recueillir ce que possède l’équipe. Dans ce cas, un Product Backlog, des items à spécifier, et d’autres à développer. On se focalise alors sur les processus mis en place par l’équipe (exemples : processus de découpage d’une EPIC en US, processus de développement…). C’est exactement le même point de départ que pour l’équipe précédente, dans un contexte plus agile.
Ensuite, il s’agit d’observer les espaces disponibles (murs, tableau blanc, écrans…) et de construire le management visuel sous forme de parcours. On affiche tout ! Les irritants des utilisateurs, leurs souhaits, une Story Map version géante avec des maquettes, les User Stories prêtes à être développées, le processus de développement, les rétrospectives… En grand ! Puis on l’utilise, chaque jour.
- Pour intégrer les nouvelles personnes et présenter le projet : on oublie les présentations sur power point. Le management visuel sert à raconter l’histoire vécue par l’équipe. Lorsqu’une nouvelle personne intègre l’équipe, on peut lui expliquer le contexte ainsi que toutes les activités de l’équipe en s’appuyant sur les supports visuels et les rituels associés. La personne va plus facilement pouvoir se situer et s’intégrer dans son nouvel écosystème. Lorsqu’un sponsor ou un manager souhaite avoir de la visibilité sur le projet, il est aussi possible de lui montrer des éléments en s’appuyant sur certains visuels clés.
- Pour promouvoir l’auto-organisation : le management visuel permet à l’équipe d’avoir un support d’échange commun et facilite donc le partage d’informations. C’est aussi un appui pour faciliter les rituels Scrum. Pour arriver à cela, le facilitateur doit rendre les supports suffisamment simples et explicites et accompagner l’équipe à les utiliser de manière autonome (il ne met pas les Post-It à jour !). Une légende doit également être ajoutée aux panneaux afin qu’ils soient autoporteurs, et donc facilement lisibles et utilisables. Cela passe aussi bien-sûr par une bonne connaissance des processus de l’équipe, où chacun sait à quelle étape il intervient. L’utilisation quotidienne des panneaux visuels crée une dynamique de groupe et favorise une communication orale et directe.
- Pour piloter l’activité : plusieurs moyens existent pour gérer l’activité de manière visuelle. Le premier est de visualiser les dysfonctionnements à travers des Post-It/gommettes de couleur rouge. Le second est de mettre en place divers indicateurs qui, à partir d’un certain seuil, doivent déclencher des actions correctives, par exemple les Burn up/down charts, le stock d’User Stories prêtes à être développées… Le graal est d’avoir un écran de monitoring pour afficher les informations en temps réel, comme suivre la production par exemple. L’équipe doit être à l’aise avec les indicateurs mis en place, et le facilitateur doit les introduire par étapes.
- Pour donner envie : on n’hésite pas à personnaliser les panneaux, avec des avatars, de la décoration (“masking tape”, couleurs, Post-It à formes…), des citations, et l’on prend soin d’occuper l’espace en créant de grands managements visuels. Ils vont attirer l’œil de l’équipe et de toute personne qui va passer la voir. D’une part, cela va créer ou renforcer les liens avec les autres collaborateurs, et d’autre part les bonnes pratiques vont se propager dans d’autres espaces de l’entreprise. Cela peut prendre un peu de temps au départ en terme de création, mais il ne faut pas négliger l’aspect joli, ce n’est pas toujours de la sur-qualité. Attention à ne pas figer le management visuel ! ll est important de conserver l’aspect évolutif du management visuel et ne pas noyer l’information utile.
Le management visuel se doit d’être évolutif, surtout après les premiers mois de sa mise en place, car les processus évoluent et les personnes de l’équipe s’approprient les panneaux. Il ne s’agit pas de faire bon du premier coup, mais plutôt d’adopter une démarche itérative et d’introduire les bons outils au bon moment, comme les indicateurs par exemple. L’utilisation du management visuel doit quant à elle se faire dès que possible. Les éléments affichés doivent être partagés, et présentés à l’équipe en amont. Il ne faut pas afficher des éléments avec lesquels l’équipe ne se sent pas à l’aise.
On peut constater une bonne appropriation de cet outil lorsque l’équipe commence à réaliser des modifications ou initie elle-même certains panneaux.
Le management visuel ne doit pas être vu comme une double saisie pour l’équipe (papier / outils informatiques). Il s’agit plutôt de trouver un équilibre entre ce qui est indispensable de conserver (privilégier l’outil informatique), et ce qui est valide à un instant T et qui peut être déplacé (une User Story). Il ne faut pas oublier « [qu’] en communication visuelle on ne transmet rien, on construit un champ d’informations cohérentes et on organise l’accès à ce champ », Michel Greif, L’Usine s’affiche.
Le rôle du Scrum Master
Le travail et les Soft Skills du Scrum Master sont déterminants dans la mise en place du management visuel. Il va pouvoir solliciter l’équipe pour l’initialisation des panneaux et ainsi susciter leur adhésion. Il pourra se montrer créatif en captant les propositions et en la guidant à construire les visuels qui lui seront utiles dans le quotidien. L’idée est de donner envie à l’équipe de les utiliser. La conduite du changement est ici dans l’appropriation de l’équipe des outils mis en place, encore une fois dans le but de favoriser l’auto-organisation. Après la mise en place des panneaux, lors des rituels, le Scrum Master doit rappeler les règles d’utilisation pour ancrer les pratiques.
Cette conduite du changement doit également être réalisée auprès d’autre personnes comme les managers, afin qu’ils apprennent « à lire » l’activité de l’équipe, à mesurer l’avancement via les indicateurs, et à détecter les dysfonctionnements en observant les panneaux. Un bon moyen de voir qu’un manager s’est approprié les outils est de constater qu’il arrive à les expliquer lui-même, et qu’il utilise les indicateurs de l’équipe lorsqu’il doit rendre compte de l’activité. Le Scrum Master doit créer une relation de confiance avec les parties prenantes, et expliquer son rôle, qui n’est pas encore toujours compris en entreprise.
Enfin, le Scrum Master doit faire preuve de proactivité et sortir de ses sentiers battus, rencontrer ses pairs et progresser collectivement. Les sources d’inspiration se trouvent partout et les bonnes idées se répandent très vite !
À vous de jouer !