Module Management Visuel : Mise en oeuvre (Partie 2)

Suite à une semaine d’expérimentation du Stand-up Meeting par l’équipe, nous arrivons au second workshop de mise en oeuvre : une bonne occasion de capitaliser les apprentissages et d’effectuer la marche suivante. Plus qu’un simple tableau d’avancement décrivant les étapes d’un processus, nous allons tenter de donner plus de structure au Management Visuel afin d’obtenir plus d’informations rapidement.

Je décrirais dans cet article comme d’habitude les intentions derrière le cadre proposé, le processus ainsi que les résultats obtenus.

Les articles liés :

• Agile Rocket : Module Management Visuel
• Workshop 1 : Kick-off
• Workshop 2 : Au Tableau
• Workshop 3 : Mise en oeuvre (Partie 1)
• Workshop 4 : Mise en oeuvre (Partie 2)
• Module Management Visuel : Rétrospective et clôture

Organisation du workshop

Le groupe étant formé d’une quinzaine de personnes, il me semblait nécessaire de former des sous-groupes afin que tout le monde puisse s’exprimer et s’approprier le résultat des réflexions du collectif. J’ai donc décidé de m’inspirer du format World Café pour permettre de traiter plusieurs thèmes en même temps.

Cela s’est donc organisé de la manière suivante :

• Des sous-groupes se réunissent autour d’une thématique donnée
• A chaque timebox définie, chacun est libre de tourner sur les autres thématiques
• Un(e) référent(e) est nommé(e) par sous-groupe pour partager le fruit des réflexions aux autres, il/elle sera donc tenu(e) de rester au même endroit pendant la quasi-totalité de l’activité

Les 3 thématiques sélectionnées sont :

• AMELIORER l’existant
• ETENDRE le processus
• ZONES pour élargir le management visuel au-delà de la simple progression du travail

Pour chaque thématique, j’ai donné quelques idées pouvant être discutées par le groupe. C’est une liste non exhaustive bien sûr mais cela donnait tout de même les pistes qui me semblaient les plus pertinentes à traiter dans un premier temps. L’objectif n’est pas de tout faire mais de co-construire ensemble : rappelons nous que le processus est tout aussi important que le résultat ! 😉

Améliorer

Template de ticket

La standardisation de la rédaction d’un ticket a de nombreux avantages. Cela entraine tout d’abord en terme de processus une réflexion sur les informations strictement nécessaires afin de prendre une décision. L’espace en est ainsi mieux utilisé et cela permet au groupe de savoir où trouver quelle information : on accélère de manière directe l’accès à l’information qui peut être une des causes de non-décision et de perte de temps.

Granularité des éléments affichés

Dans le workshop précédent, l’important était de visualiser les éléments afin de pouvoir commencer à travailler avec. J’ai donc volontairement laissé libre la taille des sujets exposés sur un Post-it pour encourager l’action plutôt que la recherche de la meilleure solution – qui dans le cas du choix de la granularité, est souvent source de débats.

Le fait de traiter ce sujet maintenant peut être intéressant car cela survient après l’expérimentation du Stand-up Meeting pendant une semaine. En effet, la granularité des éléments a un impact direct sur les mouvements observés sur le board : le fait que cela ne bouge pas génère souvent des discussions.

Le choix revient bien évidemment à l’équipe qui, quoi qu’il arrive, apprendra par la pratique. Maintenant, je me permets souvent de dire que :

Tout ce qui est implicite n’est pas explicite.

Ainsi, une granularité trop élevée peut entrainer une mauvaise interprétation de l’information : un bloc immobile ne précisant pas que l’on ait pu en terminer une partie. Une granularité trop petite nécessite généralement un effort considérable : le ratio effort/valeur risque de ne pas être très intéressant.

Un juste milieu est donc à trouver pour que les éléments se déplacent régulièrement avec le juste nécessaire d’informations. Une taille de User Story est généralement convenable.

Lignes de nages – correspondant ici à des catégories

Suite au workshop précédent, j’avais le sentiment que le nombre de lignes de nages était peut-être trop important par rapport à leur véritable utilité dans le processus de mise en action du groupe. Après une semaine d’expérimentation, avec les idées plus claires, je pensais intéressant de challenger la classification initiale pour trouver des regroupements plus pertinents.

Note : Comme la plupart du temps lors des ateliers d’émergence de ce type, que ce soit pour le processus ou pour la catégorisation, les participants ont tendance à vouloir trouver « la bonne solution » et rentrent donc souvent dans une complexité plus élevée que nécessaire. Selon le temps alloué, je préfère que la simplification vienne du groupe plutôt qu’elle soit imposée par le cadre (moi donc !).

Couleurs

Nous n’avions pas discuté des couleurs au workshop précédent. Les participants avaient juste pris les couleurs qui leur tombaient sous la main (ce qui était un acte volontaire de ma part). En effet, le questionnement sur les couleurs arrivent naturellement au bout d’un moment et la répartition des couleurs sur le board donne déjà une idée des informations supplémentaires que cela pourrait apporter.

La difficulté principale provient donc du choix de la notion représentée par la couleur :

• Typologie d’élément (bug, évolution, …) ?
• Taille (nombre de jours, taille de T-Shirt, …) ?
• Classe de service ?
• Source de la demande ?
• Priorité ?
• …

Signaux visuels spécifiques

En plus ou indépendamment de la couleur des éléments de travail, il peut être intéressant de visualiser des informations nécessitant une attention ponctuelle :

• Urgence (« il faut le traiter rapidement car plus on attend, plus cela nous coûte !« ) : A traiter en priorité
• Questionnement (« j’ai des interrogations qui m’empêchent d’avancer correctement sur ce sujet« ) : A remonter en Stand-up Meeting
• Risque (« il faut surveiller cet élément car il risque de générer l’impact X » ) : A suivre dans le temps au travers du Stand-up Meeting
• Avatar (« Qui travaille sur quoi ?« ) : Permet l’identification rapide de la répartition du travail

Note : Vous pourrez remarquer que l’équipe n’a pas attendu ce workshop pour mettre en place les avatars et les signaux de danger sur leur board ! Initiative du groupe 😉

Dépendances entre éléments

Peut-être que cela provient de l’atelier Au Tableau ou d’une inspiration de SAFe, mais la notion de dépendance est quelque chose qui a souvent beaucoup d’impact sur la production de valeur. Le fait de réfléchir à la question peut également aide le groupe, initialement composé d’une somme d’individualités ne travaillant pas forcément sur les mêmes sujets, à porter un regard collectif sur la gestion de leur travail.

Étendre

Processus d’alimentation du flux

Pour aller plus loin que simplement la visualisation du travail à faire, il paraissait intéressant d’étudier le processus amont du traitement des demandes. En effet, j’avais cru comprendre que l’équipe se sentait souvent en surcharge de travail. Ainsi, définir des critères d’acceptation est un bon moyen pour pouvoir dire « Non » en entrée de manière informée et limiter l’effet de la surcharge.

Pour ce faire, je leur propose non seulement de réfléchir sur ce dont ils ont besoin pour considérer une demande comme pouvant être acceptée (prise en charge), mais aussi sur les différentes sources de demande. En effet, il arrive souvent que selon l’origine de la demande les critères diffèrent et c’est un sujet important sur lequel échanger en groupe !

Destinataires

Même idée que pour le processus amont, il peut être intéressant d’étudier le processus en aval du traitement des demandes. Cela est moins souvent fait dans mon expérience mais je pense que cela peut avoir de la valeur lorsque l’on a différents types de destinataires car qui dit « destinataires différents » dit « besoins ou attentes différentes » ! 😉

Ownership des activités

Selon le métier, nous n’avons pas toujours la main sur toutes les activités liées à notre flux de valeur. L’intention de ce sujet sur l’ownership des activités est de ré-étudier le processus définit lors du précédent workshop pour voir si effectivement il n’y aurait pas des étapes sur lesquelles l’équipe ne peut pas directement agir. Matérialiser cette étape peut permettre à l’équipe de remonter des blocages potentiels plus facilement et de visualiser leur impact sur leur productivité.

Un exemple que j’avais pu rencontrer dans le cadre d’une équipe support était qu’elle ne « corrigeait » pas directement les problèmes mais était responsable du « suivi » du début à la fin du processus de correction. Elle a matérialisé une étape « Suivi » – consistant principalement à relancer les services concernés – faisant partie intégrante de leur flux de valeur mais dans laquelle l’équipe était surtout en attente. Cela leur a permis de visualiser l’ensemble des sujets en cours et de prendre des décisions plus pertinentes par la suite.

Éléments gelés

Il arrive parfois qu’un sujet soit mis de côté pendant un laps de temps donné. Habituellement, on le garde dans le processus comme étant un élément bloqué afin de bien matérialiser le fait qu’il a bien engendré un effort de réalisation. Maintenant, lorsque le board devient un peu chargé, il est parfois intéressant de déplacer les éléments gelés sur une autre partie du Management Visuel. C’est un petit peu comme au foot lorsqu’un joueur est blessé, on ne va pas le laisser allongé sur le terrain alors que les autres vont jouer autour, on le sort pour traiter son cas en séparé ! 🙂

On pourrait considérer cela comme étant une zone supplémentaire par laquelle on passerait lors du Stand-up Meeting afin de ne pas les oublier.

Noms de colonne

Je rappelle que nous avions fait le choix lors du dernier workshop de garder 3 mots pour chaque étape du processus « En cours ». L’idée était simplement de prendre du recul après l’utilisation du board pendant une semaine sur la terminologie qui serait la plus parlante pour tout le monde. Encore une fois, plutôt que d’être dans un processus de prédiction afin de trouver « LA solution », l’équipe est dans un processus d’apprentissage par l’expérimentation. Cela lui permet ainsi de prendre une décision informée à chaque adoption.

Zones

Zone Équipe

Cette zone a pour intention de partager les informations liées directement aux membres de l’équipe. Cela peut comprendre par exemple :

• Les règles ou charte d’équipe
• Les différents rôles définis dans l’équipe
• Les dates importantes (événements, anniversaires, …)
• Les congés, absences
• Les compétences (souvent représentées sous forme de matrice)
• …

Zone Challenge

Cette zone a pour intention de partager les informations liées à l’objectif que l’équipe doit atteindre. Cela peut comprendre par exemple :

• L’expression de la vision stratégique, la vision / mission de l’équipe
• L’avancement par rapport à l’objectif global
• Les chiffres importants
• Les jalons importants
• …

Zone Performance

Cette zone a pour intention de partager les informations liées au système de production de l’équipe. Elle permet avant tout à l’équipe d’obtenir du feedback au travers de métriques d’apprendre et de générer des actions d’amélioration. Cela peut comprendre par exemple :

• Nombre d’éléments terminés (sur une période de temps donnée)
• Nombre d’éléments en cours (sur une période de temps donnée)
• Nombre de blockers (sur une période de temps donné)
• …

Zone Informations

Cette zone a pour intention de partager les informations liées à des processus ou des connaissances nécessaires à l’équipe pour effectuer son travail de manière plus efficace. Cela peut comprendre par exemple :

• Des diagrammes de processus
• Les coordonnés d’interlocuteurs privilégiés
• …

Débriefing

Voici le résultat en sortie de workshop :

Les changements apportés à la version précédente de Management Visuel sont donc les suivants :

• Une sélection d’un terme unique pour les étapes du processus
• Une simplification des lignes de nages, de la catégorisation initiale
• Un système de couleurs basé sur les sources (origines) des demandes
• L’application d’un template de ticket

La réflexion sur les critères d’acceptation et le processus en amont a également eu lieu mais les contraintes d’espace (placards) ont rendu sa mise en oeuvre difficile comme le montre la photo ci-dessous :

Note : La photo exposée ci-dessus a été prise plus tard dans la journée. Elle ne montre ainsi pas visiblement l’ensemble des modifications prévues car nécessitant une refonte des tickets dans leur intégralité. On peut cependant voir sur la droite que les règles du Management Visuel ont été affichées, avec le fameux template ! 😉

Nous nous reverrons dans un mois, pendant lequel l’équipe expérimentera de manière autonome. Le workshop suivant est libre, c’est-à-dire sans contenu prédéfini, pour échanger sur leurs problématiques du moment.

Conclusion

Le Workshop 4 du module Management visuel a pour but d’itérer sur la version actuelle de l’équipe en capitalisant sur leur expérience d’une semaine d’utilisation.

Il s’avère que cette équipe a été particulièrement pro-active, déjà pendant la semaine d’expérimentation et avait donc déjà opéré des changements notables comme la mise en place des avatars et d’indicateurs spécifiques. Nous avons donc continué dans le même esprit que précédemment en mettant en oeuvre en processus permettant l’échange et la collaboration des participants pour construire cet outil qui est le leur.

Le prochain article décrira les résultats obtenus lors de la rétrospective de clôture du module Management Visuel ! 🙂

Remarque : le workshop 5 étant libre, il ne sera donc pas traité dans la série d’articles.