#ControleQualité en environnement #Lean / #Agile

L’entreprise pratique les développements de manière structurée depuis des années, et une partie de cette expérience accumulée conserve sa valeur, que par le passé on a tenté de capitaliser dans un processus, pour éviter de faire plusieurs fois les mêmes erreurs.

L’entreprise a aussi choisi de se transformer radicalement en adoptant les approches lean/agile, en instaurant notamment l’amélioration continue et globale et l’adaptation au contexte des projets.

Cette dualité entre capitalisation et adaptation pose des questions sur la garantie qualité des projets. La garantie qualité c’est le contrôle par un tiers de la conformité au processus. Si l’on admet l’idée d’une adaptation permanent, à quoi doit-on rester conforme ?

Les projets agiles doivent intégrer ce souci de contrôlabilité puisque l’entreprise a choisi de mettre en place cette démarche qualité, et ne s’est pas cantonnée à la sensibilisation et à la formation des équipes.

CONTROLABLES

Les projets doivent être contrôlables facilement (le contrôleur regarde les preuves, les traces) :

• Adapter de manière réfléchie et formalisée, ce qui n’est pas compatible avec une démarche Scrum ou Kanban (qui insiste encore plus sur le côté scientifique avant/après des actions d’amélioration)
• Les projets doivent décrire leurs choix de fonctionnement : definition of done, checklists, …
• Les projets doivent rendre visible et transparent leur fonctionnement : management visuel clair, explicite, lisible.

REGARD

La qualité est dans le regard de celui qui regarde :

• Le regard du contrôleur doit évoluer, pour aller du processus vers les principes sous-jacents du processus, en considérant notamment les grands principes lean ou agiles que l’on essaie d’implémenter.
• La capacité du contrôleur qualité, de par son expérience, à envisager ce qui va se produire si l’on fait quelque chose d’un peu nouveau se substitue à celle de comparer à un processus de référence.
• Les normes qualités doivent évoluer, pour modifier la nature des points que l’on contrôle. Contrôler le résultat (« l’équipe réussit à livrer les user stories qu’elle a envisagé en début de sprint ») plutôt que le moyen (« l’équipe fait une démo en fin de sprint des user stories qu’elle a livrées »). Evaluer le résultat du résultat (auditer la satisfaction client, évaluer les retours signalés après la mise en production, …) , ce qui suppose que l’on livre en production souvent, sinon le résultat du résultat arrive trop tard.
• Les pratiques du contrôleur change, pour passer d’un contrôle rare, long et souvent à distance (à base de document) à un contrôle fréquent, plus bref, sur site (« Gemba »), ainsi qu’une présence lors de cérémonies.

VARIABILITE

Ces contrôles seront difficultés à effectuer: les projets seront tous différents. Les contrôleurs qualité ont souvent dans leur escarcelle de nombreux projets, s’adapter à chaque fois demande un effort certain.

Par exemple : Imaginez… Trois mondes parallèles où existe le même projet… Dans chaque monde, le projet est contrôlé… Les contrôleurs qualité sont différents. Ils examinent la même situation, font un diagnostic légèrement différent, et optent pour des conclusions et actions différentes. Les projets évoluent dans des trajectoires différentes. Il n’y a pas de processus général de la vie d’un projet, il n’y a que des principes, un jugement humain sur ce qu’il faut changer. Même l’évolution de la maturité d’un projet va potentiellement varier d’un contrôleur à l’autre.

ANALOGIE

Fils de médecin, je vois un peu l’accompagnement d’un projet comme un diagnostic médical. Examiner les symptômes (les signes de disfonctionnement), connaître le fonctionnement général d’un projet informatique tout en intégrant les spécificités d’un cas concret, son historique, la coexistence potentielle de plusieurs pathologies. Décider d’une prescription ou intervention, en suivre les conséquences, réitérer.

Si les médecins jouent aux dés, ils « trichent » en obtenant des statistiques sur l’impact de tel médicament dans tel contexte, pour battre le hasard. Ce qui manque, au contrôleur agile, c’est une phénoménologie scientifique donnant les probabilités de succès d’une action ou d
’une autre selon le contexte.

L’analogie m’amène à voir aussi les rôles d’accompagnement comme un médecin généraliste, qui ferait intervenir un expert du leandesign, de l’intégration continue ou un expert de l’automatisation des tests. L’adoption de communautés de pratique dans l’entreprise pourra faire émerger, à défaut d’un consensus, des interlocuteurs fiables, sur ces différents sujets.

Cette analogie, comme toute analogue, a ses limites : la médecine a un consensus sur le fonctionnement « normal ». Pour la transformation agile, il me semble plus judicieux de miser sur une montée en maturité des équipes. Il peu s’agir d’agilité en général, ou, selon les centres d’intérêts et les situations sur des points plus spécifiques. Les contrôleurs mettront à profit cette maturité, les experts émergents se substituant à une savoir phénoménologique figé, le contrôle étant fait en premier approche par ces contrôleurs qualité.