Une des plus grandes problématiques qui attend les organisations qui cherchent à créer une culture d’amélioration continue est le besoin sous-jacent de toujours avoir quelqu’un à blâmer et la façon dont ce besoin est très présent dans le langage de ses équipes au jour le jour. Cela nourrit souvent des relations antagonistes plutôt que la véritable collaboration nécessaire à une culture d’amélioration.

Parfois, le langage et le fait de pointer du doigt sont très évidents avec des phrases comme :

  • Si ça échoue, des têtes vont tomber!
  • Mais qu’est-ce que c’est que cette « M3RD3! »?
  • Qui a fait ça?
  • C’était l’idée de _______?
  • Qu’avez-vous pensé?
  • Cette équipe (ou cette personne) nous envoie toujours des conneries.

D’autres fois, le phrasé est plus subtil :

  • Pourquoi cela a-t-il été fait?
  • Avons-nous envisagé des alternatives?
  • Nous n’avons pas la permission de faire ça.

En fin de compte, il est possible que nous jugions des projets à venir en fonction de résultats antérieurs ou de préjugés :

  • Nous avons déjà essayé ça.
  • Ça ne fonctionnera pas ici.
  • La dernière personne qui a essayé ça a fini…

Quand ces exemples deviennent le langage de votre équipe ou de votre organisation, il est très difficile pour les programmes d’Amélioration Continue (A.C.) de s’enraciner, parce que les parties prenantes deviennent réticentes à expérimenter. Encore pire, il est difficile de faire s’engager les autres dans votre occasion d’amélioration si vous commencez en les mettant sous tension. Je peux vous garantir que si vous effectuez des changements pour améliorer un processus sans impliquer les autres acteurs essentiels, vous ferez l’expérience de la « saveur du moment » avec des changements qui ne collent pas et pire, une escalade de la dynamique de blâme.

Cela me rappelle un cas que j’ai vécu tôt dans mon cheminement d’amélioration continue alors que j’assistais un collègue avec un long problème que nous cherchions à résoudre. Voici son histoire (les noms ont été modifiés) :

Marc fournissait du soutien à un groupe de techniciens qui utilisaient leurs ordinateurs portables pour installer notre produit chez les clients. Il m’a approché avec un problème qu’il cherchait à résoudre.

Marc avait remarqué que quand « ses » techniciens recevaient de nouveaux ordinateurs portables (un processus appelé « Renouvellement continu »), il leur manquait souvent l’ensemble des outils nécessaires pour satisfaire les besoins de leurs clients, puisque les nouveaux ordinateurs n’avaient pas les programmes et interfaces requis pour accomplir leur travail.

Marc a continué à décrire la quantité de temps perdu les techniciens ainsi que lui-même, tandis que les besoins du client demeuraient insatisfaits. Il blâmait carrément Alain, le gestionnaire du programme de renouvellement, pour ces carences. En fait, dans sa frustration, Marc avait commencé à faire allusion à Alain comme « ce p*!?$% d’Alain ». Pas vraiment un bon endroit pour commencer une initiative d’amélioration continue!

J’ai passé environ trente minutes avec Marc pour l’aider à réunir les détails en utilisant mon processus d’amélioration continue simple. Nous avons défini :

  • Le problème
    • Quand les ordinateurs portables des techniciens sont remplacés, il manque souvent les outils, programmes et liens nécessaires pour accomplir leur travail.
  • Le souhait
    • Quand un technicien reçoit un nouvel ordinateur, il devrait contenir tous les outils, programmes et liens pour être complètement fonctionnel sans délai.
  • Les désagréments (qui ont ensuite été estimés en termes de temps et d’argent)
    • Du technicien
      • Temps supplémentaire nécessaire pour accomplir son travail.
    • Du client
      • Temps d’attente supplémentaire pour obtenir le service.
      • Possibilité d’un délai de service encore plus long si un nouveau technicien doit être embauché.
    • De l’entreprise
      • Le coût lié à l’assignation d’un deuxième technicien.
      • Possibilité d’affecter la marque (si nous ne sommes pas en mesure de faire fonctionner notre propre technologie, comme ferons-nous fonctionner la leur)
    • De Marc
      • Incapacité à faire rouler les techniciens à pleine capacité.

Une fois que nous étions tous les deux confiants que ce document simple pouvait fournir un point de départ pour une discussion avec Alain, nous avons prévu une conférence téléphonique avec lui. Notre plan était que Marc allait lui faire part de nos observations et voir quelle était sa perception. Notre mesure de succès pour l’appel était d’arriver à un accord avec Alain à propos d’où nous étions maintenant, d’où nous voulions être plus tard et de pourquoi nous devions effectuer les changements.

Je fais souvent référence à cela comme le fait d’aller en voyage. Si nous allons être des compagnons de voyage, nous avons tous besoin d’un point de départ commun, d’une destination commune, et tout le monde a besoin d’avoir au moins une raison quelconque (ou la perception d’un avantage) de faire le voyage.

L’appel a eu lieu quelques jours plus tard. En tant qu’organisateur, j’ai fait les présentations et expliqué que Marc m’avait approchée avec une occasion d’amélioration et qu’il voulait son avis. J’ai ensuite laissé la parole à Marc pour mettre le plan à exécution. Je ne me doutais pas qu’il utiliserait mon mot si littéralement! Plutôt que de partir des documents que nous avions préparés, Marc a commencé à attaquer Alan avec des questions comme : « Pourquoi tu fais ça? », « Pourquoi tu ne fais pas ça? » et à fondamentalement remettre en question le travail d’Alain. J’ai arrêté Marc et lui ai demandé s’il était d’accord que je partage le document que nous avions préparé. Une fois que j’ai eu partagé poliment le problème de Marc, j’ai demandé à Alain de nous offrir sa perspective.

Le sommaire des défis auxquels il faisait face dans le cadre du processus a changé l’attitude de blâme de Marc pour la transformer en une de sympathie. Il posait dorénavant des questions comme : « Tu veux dire que tu n’as pas de visibilité sur ça? » ou « Tu n’as pas accès à ça? » et a terminé avec empathie en disant : « Mais comment arrives-tu à faire ton travail? » Quel changement de ton!

Nos discussions ont pris une nouvelle tangente et Alain est devenu un partenaire de la solution que nous avons fini par mettre en place pour les techniciens avec lesquels Mark travaillait, mais aussi pour l’ensemble des techniciens de l’entreprise (ce qui a permis d’économiser plus d’un million de dollars annuellement!)

Aujourd’hui, je continue de raconter cette histoire à propos du fait qu’aller au-delà du blâme nous permet de construire des équipes collaboratives. Ma question pour vous est : qu’êtes-vous prêt à faire avec cet apprentissage?

  • Allez-vous examiner votre propre langage et votre utilisation du blâme?
  • Allez-vous effectuer des vérifications semblables au sein de votre équipe?
  • Allez-vous être assez aimable pour partager vos idées et commentaires à propos de ce billet?

Savoir Agile

Billet précédent

AME : Murphy, Taleb et Schumacher démystifient la proactivité

Billet suivant

Tension dans les équipes Agiles : Parties prenantes et rétroaction

2 Commentaires

  1. ltremb.t@gmail.com'
    Louis Tremblay
    18/09/2018 at 09:29 — Répondre

    I share your view 100% and the process you described is excellent !

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.