Pensée systémique

Un système est plus qu'une collection de parties. C'est les parties plus leurs interactions. Et souvent, les interactions comptent plus que les parties elles-mêmes.

Prenons une équipe logicielle. Vous avez des développeurs, des designers, des ingénieurs QA, un gestionnaire de produit. Chaque individu peut être excellent. Mais s'ils ne communiquent pas bien, si les transferts sont maladroits, si les incitatifs sont mal alignés — l'équipe sous-performe malgré le talent.

La pensée systémique signifie comprendre l'ensemble du système avant d'essayer d'améliorer les parties. Cela signifie se demander : Comment les pièces interagissent-elles? Quelles boucles de rétroaction existent? Quels comportements émergents apparaissent?

La plupart des dysfonctionnements organisationnels viennent d'ignorer la pensée systémique. Chaque département optimise pour ses propres métriques pendant que le résultat global en souffre. Les ventes concluent des contrats que le produit ne peut livrer. L'ingénierie construit des fonctionnalités que le marketing ne peut vendre. Tout le monde atteint ses KPI pendant que l'entreprise peine.

Voici un scénario courant : L'équipe de développement est le goulot d'étranglement. Alors la direction décide de rendre les développeurs plus efficaces. Ils suivent les story points, mesurent la vélocité, réduisent les réunions. La productivité des développeurs augmente.

Mais la livraison ne s'améliore pas. Pourquoi?

Parce que le goulot d'étranglement n'était jamais vraiment dans le développement. Il était dans le déploiement — un processus manuel et sujet aux erreurs que seule une personne comprenait. En accélérant le développement, vous avez juste créé un plus gros embouteillage au déploiement. Le délai de livraison a augmenté même si les développeurs travaillaient plus vite.

L'optimisation locale améliore une partie du système. L'optimisation globale améliore l'ensemble du système. Ce n'est pas la même chose — et l'optimisation locale nuit souvent à la performance globale.

C'est l'intuition de Goldratt tirée de la Théorie des contraintes : améliorer quoi que ce soit qui n'est pas la contrainte est du gaspillage. Si le déploiement est votre contrainte, rendre le développement plus rapide est du théâtre. Corrigez d'abord le déploiement.

Dans les organisations logicielles, les optimisations locales courantes qui nuisent globalement :

• Maximiser l'utilisation des développeurs (détruit la marge de manœuvre, augmente les temps d'attente)
• Mesurer la vélocité individuelle (incite à tricher, nuit à la collaboration)
• Optimiser le temps de compilation (non pertinent si les déploiements n'ont lieu que mensuellement)

Les systèmes contiennent des boucles de rétroaction — la sortie d'une partie devient l'entrée d'une autre. Certaines boucles sont renforçantes (amplificatrices), d'autres sont équilibrantes (stabilisatrices).

Exemple de boucle renforçante : Les développeurs prennent des raccourcis pour respecter les échéances. Cela crée de la dette technique. La dette technique ralentit le développement futur. Les équipes prennent plus de raccourcis pour respecter la prochaine échéance. La spirale de la mort s'accélère.

Exemple de boucle équilibrante : Une équipe adopte des limites de travail en cours. Le travail s'accumule. Les gens se regroupent pour aider à dégager l'accumulation. Le travail en cours diminue. Le système s'auto-stabilise.

Le comportement émergent est un comportement au niveau du système qui ne peut être prédit à partir des parties seules. Un embouteillage n'est causé par aucune voiture individuelle — il émerge de milliers de petites interactions. De même, une organisation dysfonctionnelle peut avoir tous d'excellents individus mais le système produit un dysfonctionnement.

La pensée Lean exige de prendre du recul pour voir ces modèles. Vous ne pouvez pas corriger une spirale de la mort renforçante en formant les individus. Vous devez changer la dynamique du système — généralement en changeant les incitatifs, les contraintes ou les mécanismes de rétroaction.