A la manière des formules à volonté, nous pouvons nous dire que "cela ne mange pas de pain", "au moins c'est fait".

Faux.

De cet atelier, je retiens que

  1. cela ne sert à rien de tenter d'aller plus vite que le goulot d'étranglement. C'est même mal.
  2. ce focus sur les réussites locales nuit au flux global. Faire un avion prend du papier. Écrire des spécifications prend du temps. Il y a des coûts de production pour ces objets gâchés. De plus, cela ne fait que mettre encore plus en péril la capacité de réalisation du goulot d'etranglement.
  3. pour ces raisons, il ne faut pas se tromper en optimisant quelque chose qui n'est pas sur le chemin critique.
  4. personne ne veut être le goulot d'étranglement. C'est stressant et démotivant de voir les tâches s'empiler encore et encore. C'est peut être pour cette raison qu'il est si tentant de se débarrasser d'une tâche en envoyant un mail plutôt qu'en allant voir les personnes.
  5. pour débloquer le goulot d'étranglement, l'entraide directe est une solution de dernier recours. Avant d'en arriver là, le goulot lui même peut avoir des idées pour s'aider, mais il faut l'aider à lever la tête. Les autres services ont également des leviers : en amont, nous pouvons l'aider avec des users stories bien délimitées pour lui épargner des hésitations. En aval, partager avec le développeur le critère de succès lui donne les moyens de tester efficacement sa production et ainsi éviter les retours de recette. Je pense que le plus dur au quotidien est de dépasser le "on n'y peut rien" et de se rendre compte que le changement est possible quelque soit notre place dans l'équipe. On peut aussi sortir du cadre et tordre le système.
  6. le feedback et la mesure sont des bons moyens d'obtenir un système équilibré

Merci donc à Pascal pour ce "vieux" jeu qui est toujours bien d'actualité !