Inspection, adaptation et théorie des contraintes

L’amélioration continue est un sujet central dans le fonctionnement actuel de nos équipes. Que l’on parle d’équipes de développement qui adoptent l’approche agile ou d’équipes de création de produit, de suivi de clientèle… le sujet est au coeur des préoccupations du management mais aussi source de beaucoup de débats.

La nécessité d’amélioration est réelle, que ce soit au niveau individuel, qu’au niveau de l’équipe, de l’organisation, du produit ou service délivré… Cependant il faut faire attention à la manière d’initialiser le mouvement.

Avant toute chose, il faut comprendre que l’amélioration continue entre dans un cycle d’inspection et d’adaptation qui sont des piliers de l’empirisme. Il suffit d’y ajouter la transparence et vous avez le trio gagnant.

Mais il ne faut pas oublier de prendre en compte ce à quoi nous nous attaquons. En effet, tout n’est pas forcément sujet à amélioration, surtout si, pour le moment, le frein rencontré est hors des responsabilités de l’entité (individu ou équipe) tentant de l’améliorer. De plus, il faut faire attention à aborder les freins correctement. La théorie des contraintes nous montre que l’efficacité d’un système dépend de ses goulots d’étranglement mais tous n’ont pas le même impact et il faut correctement diriger nos efforts si nous voulons voir un résultat positif sur l’efficacité de l’entité (individu, équipe, organisation) ou sur la valeur du produit.

Les bases de l’amélioration continue

Pour les équipes, la base généralement de l’amélioration continue est la mise en place de rétrospectives (nous avons consacré un retour d’expérience sur ce sujet ici). Il s’agira alors de s’attaquer aux sujets un à un, en privilégiant les quick win et en prenant le chemin avec des petits pas.

Quand on parle d’amélioration continue au niveau produit, il existe souvent des pistes claires, notamment si l’équipe a à sa disposition des retours clients. Cependant, les retours clients sont généralement faits par des personnes qui prennent le temps et ne représentent qu’une partie des utilisateurs. De fait, il peut être interessant de multiplier les sources d’informations. Les enquêtes de satisfaction et autres système de recueil de l’impression des utilisateurs sont bien sur les bienvenus. Dans le cadre d’un produit informatique (logiciel) on peut aussi mettre en place des outils de suivi de l’utilisation et des performances qui permettent d’avoir une vue globale sur le fonctionnement de l’application par exemple.

Ensuite, il est conseillé de diriger les efforts sur la véritable source de problème. S’attaquer au symptôme est souvent un raccourci que les équipes empruntent. Pour ne pas tomber dans ce travers, la pratique des 5 pourquoi est plutôt conseillée.

L’amélioration continue et le cycle de vie de l’objet amélioré

Toutes ces informations sont importantes à prendre en compte, cependant il apparait que l’information en entrée n’est pas la seule responsable d’une bonne amélioration continue. En effet, il est important, lorsqu’on met en place de l’amélioration continue, de prendre en compte le cycle de vie de l’objet amélioré.

Si, par exemple, vous tentez d’améliorer un processus rapide, qui se déroule toute les semaines par exemple, il faudra une ou deux répétitions de ce processus modifié avant que l’équipe ne se soit approprié le changement. Il faudra ensuite encore quelques répétitions pour en voir l’efficacité. De fait, l’équipe ne pourra juger de la pertinence de l’amélioration qu’au bout de 4 à 5 cycles.

Et c’est souvent sur ce point que les équipes entre dans un piège lié au terme amélioration continue…. la surabondance d’actions…

Si, par exemple, une équipe essaye de changer la manière dont ils recueillent les besoins utilisateurs, et que le cycle de vie de ce dit recueil est d’un mois (entre l’identification et la réponse de l’équipe) alors, pendant au moins 2 mois, l’équipe va avoir à traiter des besoins qui seront soit au nouveau format, soit à l’ancien… il faudra alors attendre encore au moins 2 cycles, soit 2 mois complémentaires pour voir le résultat. Donc un total de 4 mois avant d’avoir une confirmation de l’efficacité de l’action. Mais si, sur ces 4 mois, l’équipe change autre chose dans le processus de recueil de l’information ou de la réponse au besoin recueilli… alors l’efficacité de cette première action pourrait très bien être masquée par une autre action…

Donc, il est important de garder en tête, non seulement le cycle de vie de l’objet amélioré mais aussi les autres sujets en cours d’amélioration.

Apprendre à échouer… mais des pièges à éviter?

L’amélioration continue passe aussi par des tentatives infructueuses… souvenez vous, l’empirisme est clé dans l’amélioration continue. De fait, on ne sait si une action est efficace que si on la tente… et comme il faut prendre en compte le cycle de vie de l’objet amélioré… l’amélioration continue peut être un processus lent, contrairement à ce que son nom semble indiquer…

Alors, quels sont les pièges à éviter? Le premier piège est bien sur de prendre en charge trop d’actions d’un coup, mettant en péril le recueil de l’efficacité des actions en cours. Le second piège est de ne pas garder de trace des actions en cours… Il est conseillé de garder une liste des actions en cours comme les équipes agiles gardent une trace de leur backlog (un référentiel commun, accessible et publique). 

Un autre piège dans l’amélioration continue est de ne pas mettre de responsable de l’action. A chaque action un responsable et chaque action doit non seulement répondre à une problématique connue mais doit aussi répondre à l’acronyme SMART. (Spécifique Mesurable Atteignable Réaliste Temporel). 

Nous vous conseillons également de faire attention aux biais, à ce sujet, vous pouvez consulter le retour d’expérience sur la conférence « Nous sommes tous biaisés« .

Mes h@cktivités préférées pour aborder ce sujet