Cette fois, ça y est, c’est la bonne: on va faire un nouveau projet from scratch et c’est sûr, promis-juré, on ne reproduira pas les erreurs du passé ! On va utiliser les “bons” langages, les “bons” frameworks et les développeurs vont même écrire des tests unitaires. Cerises sur le gâteau: du TDD et une pincée de DDD parce que l’hexagonal, quoi.

Et au début, tout va bien: on développe nos fonctionnalités super rapidement et on a tous le sourire…

Mais voilà, après plusieurs mois, les développements commencent à ralentir: le code est devenu de plus en plus complexe, rajouter une feature nécessite de longs refactorings, les tests sont de plus en plus lents et certains plantent même aléatoirement, les anomalies s’enchainent, on fait plus de meetings pour essayer de comprendre, l’ambiance s’est dégradée, on blâme les frameworks, le TDD, on recherche des coupables et la chasse aux sorcières est lancée…

On essaie de se ressaisir car la deadline approche, l’équipe est débordée et le produit n’est pas prêt…on reste donc plus tard au bureau et on travaille même les weekends à présent.

On décide alors d’embaucher des développeurs supplémentaires pour aider l’équipe. Les semaines passent et malgré l’apport des nouveaux arrivants, on a toujours autant, voire plus de retard: bref, c’est la cata et on n’a pas vraiment fait mieux qu’avant !

Le Systems Thinking est une façon non conventionnelle de penser qui peut nous aider à mieux comprendre l’enchainement de ces problèmes et à identifier des axes d’amélioration souvent différents de ceux que l’on mettrait en place avec un mode de pensée traditionnel.

Le Systems Thinking est utilisé dans de nombreux contextes: économique, environnemental, social, etc. et l’objet de cette série d’articles est de l’appliquer dans le domaine du développement logiciel.

Un système, qu’est-ce que c’est ?

Avant de définir le Systems Thinking, précisons d’abord ce qu’est un système. J’aime beaucoup cette définition subtile donnée par Donella Meadows dans son livre Thinking in Systems:

an interconnected set of elements that is coherently organized in a way that achieves something

Cela dit qu’un système contient:

• des éléments
• des interconnections qui relient ces éléments
• un objectif déterminé par le comportement du système

Une équipe produit est par exemple un système: ses éléments sont les membres de l’équipe, ses interconnections sont les process, les standards, les cérémonies qu’elle utilise dans son quotidien.

Quel est l’objectif de l’équipe dans le contexte de cette définition ? Si vous en interrogez les membres, ils vous diront peut-être quelque chose du genre: “délivrer un produit répondant aux besoins de nos utilisateurs avec la meilleure qualité possible”.

Mais si vous relisez attentivement la définition, l’objectif est déterminé par le comportement du système et non par ses éléments uniquement.

Cela signifie que si l’équipe délivre aujourd’hui un produit qui apporte peu de valeur à l’utilisateur ou qui contient de nombreuses anomalies, le vrai objectif de ce système est alors de “délivrer un produit inutile pleins de bugs”.

Cela veut donc dire que l’objectif d’un système n’est pas toujours ce que l’on souhaiterait qu’il fasse. Et c’est là qu’intervient le Systems Thinking.

Le Systems Thinking

Le Systems Thinking est la capacité de compréhension des interconnections d’un système de façon à ce que l’on soit en mesure de l’influencer pour l’orienter vers un objectif souhaité.

En effet, selon cette approche, remplacer un élément d’un système par un autre aura peu d’impact sur son fonctionnement. Pour influencer un système, il faut plutôt agir au niveau de ses interconnections.

Le mode de pensée traditionnelle consiste à ne voir que les raisons évidentes d’un problème tandis que l’approche systémique estime que les causes d’un problème sont souvent indirectes et pas forcément évidentes. Dans la première approche, nous aurons facilement tendance à blâmer quelqu’un pour les problèmes que nous rencontrons au lieu d’essayer de comprendre comment nous pouvons être la source de nos propres problèmes et essayer de changer notre propre comportement.

Une autre différence entre ces deux modes de pensée est la façon dont on tente de résoudre les choses: conventionnellement, on va éventuellement prendre plusieurs initiatives indépendantes avec une vision à court terme tandis que dans le mode Systems Thinking, on va essayer de coordonner quelques changements qui vont produire un maximum d’effet.

L’iceberg

Il existe un framework qui permet de décrire une vue initiale d’un système. Ce framework, appelé “l’iceberg” est décrit dans le très bon livre de David Stroh.

Ce framework décrit plusieurs niveaux conceptuels: à chaque niveau correspond une question spécifique et un type d’action approprié relatifs au système étudié.

Le Premier Niveau: Les évènements

Notre connexion avec le monde se fait par l’intermédiaire des évènements qui s’y déroulent: ceux que les journaux diffusent, ceux que l’on reçoit via les réseaux sociaux ou au contact quotidien de nos amis, proches, voisins, etc.

En général, soit nous ignorons ces évènements soit nous y réagissons en prenant une ou plusieurs actions. Lorsqu’il s’agit d’un problème, nous tentons de le résoudre avec ce qui nous paraît être le plus évident et qui nous permettra d’éteindre l’incendie le plus rapidement possible.

Exemples de résolutions conventionnelles: Nous n’allons pas atteindre la deadline ? Rajoutons deux autres développeurs ! Les tests sont trop lents ou trop fragiles, ignorons-les !

Malheureusement, il arrive souvent que ces solutions ne corrigent le problème que temporairement ou pire, dégradent la situation.

Par exemple, ajouter des personnes tardivement dans un projet augmente de façon exponentielle les canaux de communication, annihilant les gains de productivité espérés (comme l’a déjà démontré Fred Brooks).

Ce niveau qui correspond à la pointe de l’iceberg répond à la question “que s’est-il passé ?” mais ne permet pas de réfléchir au pourquoi.

Le Second Niveau: Les patterns

Lorsque des évènements se produisent régulièrement, il est possible d’observer des tendances et des patterns utilisables pour prédire ou anticiper ces évènements.

Il s’agit du second niveau de notre iceberg. On y collecte les évènements passés pour prendre un peu de recul sur ce qu’il s’est passé au cours du temps.

Ce niveau est bien plus utile que le précédent mais il n’est pas toujours précis et il ne nous permet pas de comprendre pourquoi les évènements se produisent. Et, par conséquent, il ne nous permet pas de changer ces évènements si c’est ce que nous souhaitons faire.

Voici un exemple de pattern illustrant la complexité d’un logiciel d’aviation militaire au fur et à mesure de l’ajout de nouveaux modèles (source):

On observe une évolution exponentielle de la complexité, indicateur caractéristique d’un phénomène de cercle vicieux comme nous le verrons dans le prochain article.

Le Troisième Niveau: La structure

Le troisième et dernier niveau correspond à la structure du système et à l’essentiel de la partie invisible de notre iceberg.

C’est à ce niveau que l’on trouve les causes profondes des problèmes rencontrés: on identifie ici les forces et les pressions subies par le système. Et c’est également à ce niveau que l’on est en mesure d’influencer le système pour l’orienter dans la direction souhaitée.

Et je dis bien “influencer” et non “contrôler” car il est rare qu’un système puisse être contrôlé.

Chaque niveau a un impact sur le niveau supérieur: la structure influence les patterns qui influencent les évènements.

Les Forces exercées sur la structure du système

Il existe plusieurs types de forces qui influencent la structure d’un système. Certaines sont sous notre contrôle et d’autres pas du tout. En voici une liste non exhaustive classées du moins influençable vers le plus influençable.

• Les forces externes

Ce sont souvent celles sur lesquelles on n’a pas de contrôle: les lois, l’économie, les technologies, les concurrents, les règles de compliance, etc.

• Les forces liées au business

Ici, on trouvera par exemple le positionnement stratégique d’une compagnie sur le marché, ses stratégies de production, de distribution, etc.

• Les forces liées à l’organisation

A ce niveau, ce seront la structure du management, la hiérarchie, la culture de l’organisation, les mécanismes de récompense, etc. qui influenceront le système.

• Les forces liées aux relations entre personnes

On identifiera à ce niveau les relations, les rôles des employés, la capacité des employés à changer de rôle, la façon dont l’organisation capitalise sur la diversité, la prise de décision, etc.

• Les forces individuelles

En tant qu’individu, comment je pense, comment je me vois ainsi que mon rôle dans l’organisation, mes croyances et mes modèles mentaux influencent également la structure du système.

Pour changer un système, ce sont souvent sur ces modèles mentaux que l’on va agir: ils sont donc très importants à identifier.

Conclusion

Ce premier article nous a fait découvrir le Systems Thinking et décrit un framework pour mieux comprendre un système et les causes profondes qui génèrent les problèmes que l’on rencontre.

Dans le prochain article, nous ferons connaissance avec un langage permettant de “mapper” un système pour mieux décrire et analyser ces problèmes.