Le management visuel n'est pas une fin en soi

Le management visuel n'est pas une fin en soi

J'aimerai faire un aparté sur le management visuel. Il est souvent d'usage lors d'une transformation agile de mettre en oeuvre un management visuel rapidement voire en premier lieu.
Le bénéfice de cette mise en oeuvre est qu'on concrétise matériellement un élément préconisé par l'agilité.
Dans les esprits, le changement est amorcé, on teste un nouvel élément, et on l'utilise.


Il est vrai que mettre en oeuvre un esprit agile sur un projet demande un effort mental qui n'est pas complètement anodin.
La recherche de la valeur métier, la transparence, la qualité, l'inspection sont des concepts, et le management visuel a la vertu de pouvoir concrétiser un certain nombre de ces concepts.
On affichera un avancement à la vue de tous, concernant la transparence, on affichera le rapport qualimétrie/Tu pour la qualité, la dernière rétrospective pour l'inspection....

Malheureusement, le management visuel est souvent perçu comme un aboutissement. Un management visuel élaboré, avec la plénitude des concepts décrits dans les livres, est un souvent un point de satisfaction très important.
On aura mis en place un bac à rouge, un parking, afficher des éléments de planification, des tâches, ....

Est ce qu'ils sont bien utilisés? Est ce que le management visuel est un élément renforçant l'esprit agile de l'équipe? Est ce que l'équipe acquiert une plus grande autonomie grâce à celui ci?
Est ce que d'ailleurs, l'équipe est partie prenante de sa mise en place, ou le subit elle?

Fin et Fond

J'ai été longtemps dans le courant de mettre en oeuvre un management visuel pour démarrer une transformation.
Je me rends compte aujourd'hui, que ce n'est pas une "norme" à appliquer.

Il est important en premier lieu, d'être certain que l'équipe a bien "subi" une acculturation aux principes agiles.
Il y a un état d'esprit à acquérir, et la plupart des formations (type Scrum) sont le plus souvent données en inculquant la forme de la méthode : Les réunions à tenir, leurs temps, leurs fonctions.
Mais bien souvent, l'acquisition du fond n'est pas abordée. Il y a une transformation d'attitude, de perception à faire qui est fondamental.

La forme de SCRUM est un cadre idéal donnant un résultat idéalisé. Les gens ont besoin de cadre, cela leur donne un ensemble de règles à respecter, et une définition des rôles et des responsabilités.
Cela aide la plupart des équipes, et surtout cela aide les clients à respecter les besoins des équipes (en terme d'entrant, d'autonomie, de capacité à estimer, et fondamentalement, d'avoir des points d'échanges prédéfinis).

L'un des points du manifeste agile, malgré tout, indique que nous favoriserons les échanges et les rapports humains par rapport à la mise en oeuvre des processus et des outils.
Garder bien à l'esprit cela... Le cadre facilite la mise en oeuvre, mais la réelle mise en oeuvre, concerne l'humain, et son changement de comportement, pour arriver à un comportement agile.

Je me rend compte que bien des managements visuels sont élaborés en premier lieu par des chefs de projet, qui reproduisent physiquement, un outil de suivi qu'ils ont.
Finalement, on n'aide pas l'équipe à devenir autonome, on leur donne un moyen **Exagération** de s'auto flageller devant le chef de projet.
Mais je m'égare...

En tous les cas, si vous commencez par poser cette brique, il faut bien garder en tête, que ce premier jet est souvent un mauvais jet, mais qui peut être un premier lieu de sensibilisation.

Chaque matin, n'hésitez pas à poser la question sur l'efficience du management visuel : est ce qu'il manque une information, est ce que la structure suit finalement le rythme de l'équipe...

• N'hésitez pas à demander dans les répartitions de tâches, si la valeur métier prime dans tous les choix, et sinon, en discuter la raison.
• Vérifier que le niveau de partage de l'équipe est suffisant pour que si l'un des membres s'absente, qu'il n'y ait pas de problème.
• Vérifier que l'information affichée permette l'inspection à l'équipe : Où en sommes nous? Quelles sont les priorités? Quel niveau de qualité? Comment prévoit on de s'organiser?

Conclusion

A mon sens, le management visuel est un outil, plutôt efficace dans la majeure partie des projets. Mais la maxime est bien que nous favoriserons les échanges et les rapports humains, plutôt que les process et les outils.
Ne vous focalisez pas sur votre management visuel, mais bien sur la dynamique de votre équipe, sa prise d'autonomie, sa responsabilisation, sa capacité à prendre en charge tous les éléments du projet...
Le management visuel peut devenir un catalyseur en démarrage de projet, mais sera finalement tel un miroir réfléchissant l'âme de votre équipe.

Pascal Ogil

Management Visuel : Mise en oeuvre : le taskboard

Management Visuel : Mise en oeuvre : le taskboard

L'un des propos essentiels du management visuel est de pouvoir rendre accessible l'information à l'ensemble des participants.
Trop souvent, le responsable projet se lance dans le dessin d'un management visuel qui lui convient. Il a bien souvent l'intention de calquer son pilotage sur ce management visuel.

Quant à moi, je me porte en faux sur cette démarche. Ma démarche va dépendre de la situation projet, et de la maturité de l'équipe.
Dans tous les cas, je refais une présentation de ce qu'est le management visuel, ce qu'on peut en attendre, ce qu'il faut en attendre, les limites, l'importance de la dynamique d'équipe qui doit prendre en charge sa mise à jour et son évolution.
Je ferai un billet en ce sens.

Projet lancé

Sur un projet "lancé" qui souhaite apporter un management visuel, ou convient de l'inefficacité de son management visuel actuel, il convient de démarrer une rétrospective sur ce thème.
L'avantage d'un projet "lancé" c'est que l'équipe s'est déjà forgé une expérience, a rencontré des écueils, et peut se donner un axe d'amélioration, qu'elle ait déjà ou non un management visuel.
Il est possible pour rappel de donner un thème à une rétrospective, pour creuser tous ensemble un problème de fond. L'équipe se concentre aussi bien sur le fond que la forme, et peut être à un niveau de détail, qu'elle ne peut obtenir en travaillant sur une rétrospective générique.

J'aborde la rétrospective en présentant quelques questions sur lesquelles ils peuvent réfléchir:
-- Quelles sont vos difficultés actuelles?
-- Quel problème ce type d'organisation vous pose-t-elle?
-- Qu'aimeriez vous voir?
-- Quelle forme?
-- Quels en sont les avantages?

Le but étant que la solution émerge de l'équipe comme toujours. Néanmoins, j'apporte quelques expériences, enfin surtout des modèles en expliquant quels sont les bénéfices de chacun, et quels orientations ils apportent sur la gestion quotidienne.
Je vous donnerai quelques modèles à la fin de cet article.

Attention aux dérives. L'équipe étant dans une routine, il est fort probable, que l'équipe ait du mal à sortir du cadre, et notamment à échapper aux besoins de pilotage par le pilote.
C'est un piège doux. Le management visuel ne doit pas être une représentation de l'outil de ticketing (suivi de demandes). Généralement, cet outil a été mise en oeuvre pour des besoins soit générique, soit de pilotage.
Il est donc organisé d'une certaine manière, et ne convient souvent pas aux besoins réels d'auto gestion de l'équipe.
Le management visuel ne doit pas, et j'insiste là dessus, refléter par exemple le cycle de vie d'une demande. La demande vit sa vie dans l'outil de suivi des demandes.
L'équipe a besoin de savoir où elle en est en terme de tâche à exécutée au sein de l'équipe, qui a pris en charge le travail....

Démarrage de projet

On a deux cas, très différents : une équipe qui a déjà à son actif dfférentes expériences (agiles ou non), et une équipe plutôt débutante.

Généralement, je passe une ou deux heures avec le chef de projet en premier lieu, pour comprendre le contexte du projet, les risques visibles, la juniorité de l'équipe, les enjeux du projet.
Il est important que certains éléments visuels fassent ressortir la "surveillance" de certains éléments clefs, pour que l'équipe reste en phase avec les objectifs, surtout qu'en cas d'équipe débutante.

Je suis très favorable à l'amélioration continue, et à l'importance de l'appropriation de l'équipe de ce management visuel pour servir ses propres desseins.

Nous élaborons un premier management visuel qui est minimaliste mais qui correspond à un besoin impérieux de l'équipe de savoir ce qu'elle a à faire, et de pouvoir visualiser la quantité de travail qui lui reste.
Ma première proposition est de rester sur un colonnage à 3 états : A faire, En cours, Terminé. On obtient quelque chose de simple, d'accessible pour l'équipe, et qui en terme de mise à jour, se base sur des règles simples.
Sur cette base, je pose la question à l'équipe de savoir, si elle a besoin d'identifier rapidement certaines informations.
De fait, on va utiliser des couleurs de post it. Le jeu de couleur peut représenter alors : la typologie de demande(evolution, bug, ...), l'importance (en terme de priorité), la catégorie (design, front, back, ...).
En tous les cas, en un coup d'oeil on sait de quoi on parle.
On peut aussi faire apparaître le nom de la personne qui a pris en charge, la complexité (xs,s,m,l,xl), une date, .... L'important c'est qu'on puisse sans avoir à utiliser d'autres outils, de pouvoir organiser le travail.

Généralement, on reste sur des basiques, et à chaque période (itération, sprint, délai), la rétrospective (sans thème ou avec) apportera un certain nombre de choses sur l'organisation, et cela sera l'occasion d'apporter de nouvelles pratiques sur le tableau de tâches.

Conseils

Surtout, ne tombez pas dans le piège de faire un tableau très compliqué, avec énormément de détails, et des règles trop complexes.
Commencez par quelque chose de simple, pour vous assurer que l'équipe s'approprie réellement les mécanismes. Ce tableau vivra, et on apportera les apports régulièrement, même à l'intérieur d'une itération.
Rien n'empêche que lors d'un daily, on se rende compte d'un manque, et que l'équipe veuille consolider leur tableau à ce moment là.
L'amélioration continue n'est pas contraint par une "cérémonie". Pour rappel, la rétrospective est l'excuse pour que les gens prennent le temps d'y réfléchir.
Mais ce n'est pas le lieu unique où on peut apporter des améliorations quant au projet. Fort heureusement.

Modèles

Il existe beaucoup de variantes d'un tableau de tâche.
Ces variantes dénotent normalement d'un besoin.

Vous aurez peut être eu l'occasion de voir apparaître des lignes de nage sur un tableau de tâches. Ces lignes de nages peuvent être construites sur plusieurs modèles.

Ligne de nage : l'Homme

Celle qui est affectionnée par les pilotes généralement, est la ligne de nage qui représente une personne.
On trace une ligne par personne, tout simplement. On voit alors le post it avancé de colonne en colonne, et on voit rapidement où en est chaque personne.
Inconvénients:
-- Difficile de représenter la backlog, car la backlog n'est normalement liée à une personne, mais est dédiée à l'équipe
-- Rapidement, les colonnes vont représenter un cycle de vie, ce qui est contre la préconisation de base
-- Comment peut on partager une tâche entre plusieurs personnes?
-- Quand une tâche demande l'intervention de plusieurs personnes à différents moments de son cycle de vie, on obtient un patchwork compliqué, où les tickets entrent et sortent n'importe où dans le tableau pour une personne
-- L'équipe va rapidement se concentrer sur sa propre ligne de nage, et est challengé sur des objectifs individuels.
-- Auto organisation souvent en souffrance
Avantages:
-- Facilité pour le pilote pour organiser le travail
-- L'équipier sait exactement ce qu'il a à faire
-- on peut visualier rapidement la charge de chaque équipier, et identifier les gens sur sollicités, de ceux qui le sont moins
-- permet d'identifier des concentrations de compétences
-- permet d'identifier des problèmes d'organisation d'équipe
-- permet de rééquilibrer les charges de travail quand c'est possible

Ligne de nage : Priorité

Cette ligne de nage arrive dans un contexte particulier. On a un flux de demandes qui arrivent, et on a des engagement forts sur les priorités les plus fortes.
On crée alors une ligne de nage par priorité (P1, P2, P3, P4).

Inconvénients:
-- Quelqu'un doit s'assurer que les priorités sont bien en reflet avec la réalité. Ex : une P2 doit devenir une P1 après X j de non traitements.
-- Difficulté de bien organiser le travail, travail en urgence permanent
Avantages:
-- Equipe orientée vers le résultat

Ligne de nage : Feature

On fait une ligne de nage par feature avec une backlog sur la feature.
Inconvénient
-- Difficulté à cerner ce qui est prioritaire
-- La backlog feature évolue durant le projet, difficile d'avoir un niveau d'avancement
-- L'ajout et le retrait de feature entraine pas mal de modification du board
Avantage
-- Une vision orientée métier & feature
-- capacité à bien s'auto organiser
-- possibilité d'organiser facilement des tasks force sur des thèmes
-- facilité de créer des canaux d'aides, et de travailler à plusieurs sur des tâches.

Pascal Ogil