Dans ce dernier article, revenons sur d’autres boucles systémiques qui nous parlent de confiance.

Oser la transparence

La confiance commence par la transparence. A trop longtemps cacher les problèmes, il finissent par vous empoisonner. Rappelez-vous la métaphore des indicateurs “pastèque” : les pépins noirs au coeur du fruit se font plus rares au fur et à mesure que l’on remonte vers la surface du fruit et la chair passe progressivement du rouge au jaune puis au vert de la peau. Il en va de même des indicateurs que l’on montre au big boss. Par la magie de la globalisation ils finissent par devenir verts même si l’on n’est pas loin de s’étouffer avec quelques pépins bien noirs. Plus dur sera le retour de bâton lorsque le big boss finira inévitablement par découvrir la supercherie.

On donnera cette transparence par un tableau de suivi visuel. Il peut être physique (des post-its collés sur un mur) ou virtuel (de nombreux outils existent comme iObeya) à l’échelle d’une équipe ou d’un programme (program board SAFe qui figure en particulier les dépendances entre équipes). On y matérialise entre autres les objectifs, l’avancement (via un Kanban), les risques (cf. la matrice de ROAMing dans SAFe) ou encore des indicateurs plus techniques (bugs, état des tests, état des déploiements…)

Inviter le manager à aller voir par lui-même

L’étape suivante est d’inviter le big boss à venir voir le tableau de suivi plutôt qu’à demander du reporting supplémentaire. D’autant plus facile quand le tableau du programme est virtuel. On sort malheureusement ici de la zone de contrôle (cercle de Covey évoqués précédemment) pour au mieux investir la zone d’influence car on ne pourra jamais imposer cette discipline au big boss. Au pire, on peut exporter de l’outil de management visuel une vue synthétique, ce qui sera toujours moins long que d’entretenir un canevas de reporting supplémentaire.

La dernière boucle systémique que l’on se propose de briser ici est celle de la spécialisation des collaborateurs qui entraîne généralement des goulets d’étranglement dans le processus.

Se spécialiser et être… moins efficace !?

La meilleure clé que l’on ait trouvée pour éviter les goulets d’étranglement dans les équipes consiste à élargir les compétences des collaborateurs pour qu’ils puissent prendre en charge certaines activités lorsque le spécialiste n’est pas disponible. On ne recherche pas la polyvalence (l’individu aurait la même profondeur d’expertise sur chacune des compétences), mais plutôt une vraie expertise sur une compétence (le pied du T dans la T-shape) et des compétences complémentaires moins développées (la barre du T). Et même si un équipier n’est pas expert d’un sujet, il pourra faire avancer le travail, probablement moins vite que l’expert, mais cela restera toujours mieux que de rester bloqué. Bref, l’équipe agile se doit d’être pluridisciplinaire (toutes les compétences sont présentes pour livrer un projet de bout en bout), et les équipiers se veulent multi-compétents.

Pour atteindre cet objectif, il y a différentes techniques comme le pair-programming pour les développeurs, les ateliers d’intelligence collective en général (par exemple via des séances de CODEV), l’animation de communautés de pratiques (comme les chapîtres et les guildes dans les organisations inspirées de Spotify)

Nous voilà rendus au terme de cette petite analyse systémique. Nous espérons que ces quelques clés vous permettront de sortir progressivement des cercles vicieux induits par l’injonction du big boss à en faire toujours plus alors que les équipes sont déjà débordées.

Ce ne sont probablement pas les seules. N’hésitez pas à partager votre propre modélisation de cette situation et les actions qui permettent de la réguler.