Faites sauter le goulot

Hier s'est tenu le premier atelier Théorie des Contraintes animé par mes co-organisateurs SigmaT Claude et Thierry.

Très enrichissant. On y apprend des choses intéressantes par le biais d'un jeu simple et efficace.

Une remarque préliminaire : le terme Théorie des contraintes ne me paraît pas très vendeur. Bien plus qu'une théorie, c'est un constat de problèmes factuels et récurrents des processus dans les organisations. Et au delà des contraintes, l'exercice vise à proposer des solutions, ou plus exactement à faire émerger ces solutions de l'équipe elle-même (à l'instar de la discipline de coaching).

Principe de cet atelier

Ce jeu a été créé par Pascal Van Cauwenberghe, déjà géniteur des fameux XP Game et Business Value Game.
En français, on pourrait appeler ça Jeu du Goulot.

Il s'agit de fabriquer des bateaux et des chapeaux en papier, tout comme dans XP Game.
Mais cette fois, on utilise un workflow dans lequel 7 personnes ont chacune un tâche précise (du moins au début). On aligne ces 7 personnes côte à côte.

Le premier représente le client et formule sa demande (bateau ou chapeau) en transmettant une feuille A4 vierge au suivant. Le suivant est l'analyste, dont la tâche consiste à effectuer un premier pliage de base. Le suivant est le designer qui poursuit partiellement le pliage. Et ensuite de suite : programmeur qui finit le pliage, graphiste qui appose de petits dessins sur le pliage, testeur qui effectue un premier niveau de qualification et enfin, la personne qui prononce ou non l'acceptation de chaque pliage.

Le but est de livrer, dans une timebox de 5 minutes, des paires bateau/chapeau, de qualité suffisante pour être acceptée, tout en minimisant les gaspillages (travaux non terminés au terme de la timebox)

On déroule plusieurs itérations entre-coupées de rétrospectives avec recherches d'améliorations.

Résultats

Notre score :

L'amélioration est notable.

Problèmes mis en évidence

• Goulot d'étranglement : d'abord au poste de programmeur, puis se déplace en fonction des tentatives successives d'amélioration
• Beaucoup de gaspillages : feuilles injectées et non terminées (trop de push et pas assez de pull pour ceux qui parlent couramment Lean)
• Manque de communication, surtout remontante : chacun continue sa tâche sans se soucier des problèmes en aval
• Manque de fluidité générale : déséquilibres entre les sous et surchargés

Axes d'amélioration trouvés

1. Réorganiser l'espace de travail : notamment pour faciliter la communication qui faisait cruellement défaut lorsque les livraisons n'étaient pas acceptées et que les autres continuaient d'alimenter le processus avec les mêmes erreurs en amont. Ainsi, d'une organisation en ligne on est passé à une disposition en "boucle", de sorte que tout le monde puisse se voir et se parler et que le client soit finalement à côté de celui qui valide.
2. Fonctionner en mode pull : ne pas passer à l'étape suivante si le successeur est surchargé
3. Se forcer a s'interrompre brièvement pour demander de l'aide ou s'informer sur les problèmes naissants
4. Optimiser les tâches assignées initialement : certaines indications étaient superflues
5. Faire remonter les résultats de tests dès qu'un problème survient
6. Tester à chaque étape : si le suivant juge que ce qu'il reçoit va poser des problèmes, il le signale à son prédécesseur et le rectifie lui même pour ne pas casser le flux
7. Assister les postes en difficulté ou paralléliser des tâches sans pour autant abandonner son poste : par exemple, les personne en bout de chaîne n'ont rien à faire au début, donc autant les occuper à faire le même travail que le premier. Cela suppose une formation préalable
8. Essayer des alternatives de conception : par exemple, préparer les dessins avant le pliage.

Métaphores enseignées

Reprenons les points précédents et essayons de les ramener à la vie des projets :

1. Investir dans l'espace de travail pour faciliter la communication et les feedbacks : radiateur d'informations, proximité, convivialité etc
2. On en a parlé 1000 fois mais une de plus n'est pas du luxe : Pull, pull, pull ! Don't push!
3. L'air de rien, ce point est crucial : cela demande du courage de savoir s'interrompre pour améliorer donc fluidifier le processus. Il faut le faire
4. Encore une histoire de courage : oser remettre en question en toute honnêteté, proposer des améliorations concrètes, à faible coût, à tous les niveaux
5. et
6. Augmenter le feedback, à tous les niveaux (auto-similarité de feedback concret dixit XP) : livraisons incrémentales rapprochées, test fonctionnels anticipés, test unitaires fréquents etc
7. Binômage, revues de code fréquentes, encouragement à la polyvalence et à l'autogestion de l'équipe. Cela suppose d'abord de bien communiquer. On y retrouve aussi la notion d'investissement de formation
8. Investir dans l'amélioration technique : nouveaux frameworks, nouveaux outils pour augmenter la productivité et le bien être au quotidien. Dans notre cas, cela n'a pas porté ces fruits, tout comme parfois dans la réalité. Qui ne tente rien n'a rien...

A retenir

La grande leçon de tout ça est, une fois de plus, l'enjeu de la valeur métier. D'un démarrage en silos bien tayloriste, on arrive à une dynamique d'auto-gestion responsabilisée individuellement, collectivement focalisée sur la livraison de valeur et non plus sur des tâches microscopiques
Plus exactement, un curseur est à trouver entre la nécessité d'un workflow avec des étapes bien définies (définitions de fini pour chacune) et un mode hyper parallélisé avec des problèmes d'overhead.

Pour le développement logiciel agile :

• Un workflow peut être : analyse des stories (finalité claire, critères INVEST), développement (tests unitaires ok, refactoring ok, non regression ok, intégration ok, livraison pour tests client ok), acceptation (accepté par les personnes représentatives, ok pour mise en prod), mise en production
• La plus grande liberté étant laissée à l'étape de développement quant à la façon de s'attribuer les tâches au sein de l'équipe, tout en suivant les bonnes pratiques classiques (préférer de finir une story bloquante de haute priorité à plusieurs plutôt que d'en commencer une nouvelle par quelqu'un d'autre etc)
• En restant vigilant sur le fait que chaque membre ayant son mot à dire sur l'amélioration du processus global

Cet exercice enseigne également, ou plutôt nous rappelle, les écueils classiques des projets tels que le sur-découpage des activités de développement : architecture, analyse, conception détaillée, implémentation, tests unitaires, intégration, validation, recette. Ce phénomène étant pire quand on assigne des profils limités à chaque discipline.

Ca vous dit quelque chose ? ;-)