LeSS - Approche systémique

De Wiki Agile du @GroupeCESI
Révision datée du 1 novembre 2020 à 10:51 par Fabrice Aimetti (discussion | contributions) (Approche systémique)
Aller à : navigation, rechercher

Auteur : The LeSS Company B.V.
Source : Systems Thinking


Traducteur : Nicolas Mereaux Nime.png
Relecteurs : Christophe Gesché, Fabrice Aimetti
Date : 27/10/2020


Traduction :

LeSS - Portail Principes

Approche systémique

J’ai pris un cours de lecture rapide puis j’ai lu « Guerre et Paix » en vingt minutes. Cela parle de la Russie. — Woody Allen


"Quoi que nous fassions, le nombre d’anomalie dans notre backlog reste identique." nous a dit un jour un manager en évoquant un produit de près de 15 millions de lignes de code écrites en C et C++ et sur lequel plusieurs centaines de développeurs étaient en train de travailler. Que pouvait-il bien se passer ? L’approche systémique peut s’avérer utile dans ce cas. En petits groupes, les forces en présence peuvent rapidement être identifiées et comprises de manière informelle, mais dans le cadre du développement d’un gros produit ou de n’importe quel gros système, c’est difficile. Gerry Weinberg met en avant deux facteurs décisifs dans ce genre de situation :


Loi de Weinberg-Brooks : De plus en plus de projets informatiques sont partis de travers après que le management ait pris des décisions basées sur des modèles systémiques incorrects plus que pour toutes autres combinaisons de causes.


Erreur de causalité : Chaque effet a une cause... et nous pouvons dire desquelles il s’agit. [Weinberg92]


Ces deux facteurs reflètent bien l’impact de nos modèles mentaux sur le système, un sujet que nous reverrons plus tard dans cette partie.


Les problèmes résultant de nos modèles mentaux et de nos postulats sont un point à traiter. Un autre point est l’adoption à grande échelle de Scrum, de l’approche lean et des principes agiles en dehors du domaine du développement. Ce point est aussi présent dans la gestion de produit, les budgets, les tests, la commercialisation, la gouvernance et la politique RH. En conséquence, dans les adoptions agiles à grande échelle, il est utile de se réunir avec des collègues et de réfléchir en profondeur sur les modèles mentaux, les relations causales, les boucles de feedback et les mécanismes (ou les illusions) de contrôle dans un gros système qui va être sérieusement perturbé. L’approche systémique est l’un de ces outils de réflexion.


En 1958 la Harvard Business Review a publié un article de Jay Forrestor, professeur à la MIT Sloan School, qui a fait date “Industrial Dynamics: A Major Breakthrough for Decision Makers”. Cet article a lancé le mouvement de l’approche systémique dans le domaine des formations en gestion d’entreprise et la MIT Sloan School of Management devint célèbre pour ses formations en dynamique des systèmes. Le terme de dynamique des systèmes est parfois utilisé comme synonyme de l'approche systémique, même si ce dernier est un terme beaucoup plus général.


Le MIT a également attiré d’autres chercheurs intéressés par la dynamique systémique tel que Peter Senge[1]


En corrélation avec la loi de Weinberg-Brook, Jay Wright Forrester a montré que les décideurs à qui il avait été donné des modèles dynamiques de systèmes opérationnels et à qui il avait été demandé d’améliorer la performance opérationnelle, n’avaient fait généralement qu’empirer les choses [SKRRS94]. Il en est ressorti d’ailleurs que la plupart des personnes évaluaient mal la manière dont il faut améliorer les systèmes, et appliquaient généralement leur "bon sens", en mettant en place des solutions de contournement qui n’apportent aucune amélioration systémique à long terme.


Pourquoi le comportement d’un groupe de développement de grande taille (autrement dit un système) n’est-il pas compris ou guidé de manière compétente ? La réponse réside, en partie, dans le comportement des systèmes stochastiques avec les files et les variabilités comme nous avons pu l’évoquer avec le principe LeSS de la théorie des files d’attentes (en). Et c’est la même réponse qui est au coeur de la théorie du contrôle : la plupart des systèmes d’intérêt - tel qu’un groupe de développement de produit - ont des boucles de feedback positives et négatives ainsi qu’un comportement non linéaire. Le comportement de ces systèmes défient nos intuitions les plus profondes. Et puis il y a la question secondaire des gens.


En résumé, les raisons expliquants l’incompétence à maîtriser ou à guider un gros système sont (liste non exhaustive) :

  • le manque de connaissance des dynamiques des systèmes, des boucles de feedback, du comportement non linéaire des systèmes, et des conséquences inattendues dans les systèmes sur le lieu de travail.
  • la mauvaise compréhension des causes racines des problèmes (et de comment les trouver)
    • les causes, pas la cause ; en approche systémique, nous savons que les causes des problèmes sont multiples, indirectes et dynamiques
  • l’incapacité à savoir si ou pourquoi une solution de contournement ou une décision locale dégrade la performance globale opérationnelle.


Pour résumé, nous n'utilisons pas l’approche systémique[2].


Ces raisons sont la conséquence de l’intersection du management et de l’adoption à grande échelle des principes lean et agile. L’équipe de direction fait partie du système qui est pertubé ; si elle n’applique pas l’approche systémique, elle pourrait vraiment le perturber - et pas de la bonne manière !


Les points-clés à retenir de l’approche systémique peuvent être résumé dans les 11 'lois' décrites dans la Cinquième Discipline :

  • Les problèmes d’aujourd’hui viennent des 'solutions' d’hier.
  • Plus vous poussez, plus le système pousse en retour.
  • Le comportement va d’abord empirer avant de s’améliorer.
  • La manière la plus facile de s’en sortir conduit souvent à faire quelques pas en arrière.
  • Le médicament peut être pire que la maladie.
  • Aller plus vite c’est aller plus lentement.
  • Les causes et les effets ne sont pas étroitement liés dans l’espace et le temps.
  • De petits changements peuvent produire de gros résultats... mais les zones où l’effet de levier est le plus important sont souvent les moins évidentes.
  • Vous pouvez avoir votre gâteau et le manger aussi... mais pas en une seule bouchée.
  • Couper un éléphant en deux ne produit pas deux petits éléphants.
  • Il n’y a aucun reproche à faire.


La devise de Toyota en interne est "Bien réfléchir permet d'avoir de bons produits". L’approche systémique est un ensemble d’outils de réflexion pour aider à :

  • voir les dynamiques des systèmes - une organisation de développement est un système de personnes et de règles avec de subtiles boucles de feedback et des conséquences inattendues
    • nous pouvons apprendre à voir et ainsi à améliorer le système avec des diagrammes de boucles causales faits lors d’un atelier
  • percevoir les modèles mentaux - parmi les raisons derrière des décisions sous-optimales se trouvent des hypothèses erronées et des raisonnements incorrects
    • les diagrammes de boucles causales et les cinq pourquoi permettent de révéler tout ça
  • voir les optimisations locales - une autre source de décisions sous-optimales est l’optimisation locale, autrement dit prendre la « meilleure » décision du point de vue d’une personne ou d’un département, au détriment d’une optimisation globale qui est l’objectif au niveau système lean que de pouvoir livrer la plus grande valeur possible de très grande qualité avec un moral d’acier

This introduction is organized around the following areas in systems thinking: Learning to see (1) system dynamics , (2) mental models , (3) root causes , and (4) local optimization .

Cette introduction à l’approche systémique est présenté autour des domaines suivants : Apprendre à voir (1) les dynamiques des systèmes, (2) les modèles mentaux, (3) les causes racines, et (4) l’optimisation locale.

Seeing System Dynamics: Introduction

Voir les dynamiques des systèmes : Introduction

Static versus Dynamic Complexity

Complexité statique versus complexité dynamique

Many of us, especially in engineering and finance, are educated to master complexity of static details—learning to analyze and manage information (requirements, financial analysis, …), decompose complex structures into simpler ones, and so forth. That is, complexity of a static, information, or structural nature.

La plupart d’entre nous, notamment les ingénieurs et les financiers, ont été formés pour maîtriser la complexité de détails statiques - en apprenant à analyser et à gérer l’information (exigences, analyses financières, …), à décomposer des structures complexes en structures simples, et ainsi de suite. C’est-à-dire, la complexité d’une information qui est par nature structurellement statique.

Why do big software systems tend to degrade, with more and more time spent on defects? What might happen if the USA invades Iraq? Seeing the dynamics behind these questions involves analysis of the complexity of dynamics .

Pourquoi les gros systèmes informatiques ont-ils tendance à se dégrader malgré de plus en plus de temps passé sur les anomalies ? Qu’est-ce qui pourrait bien se passer si les États-Unis d’Amérique envahissait l’Irak ? Voir les dynamiques derrière ces questions implique d’analyser la complexité des dynamiques en jeu.

In contrast to static-details education, many of us receive no formal education in analyzing dynamics complexity3, especially workplace dynamics. Perhaps there is a belief it is sufficient to rely on common sense in the workplace. Forrester demonstrated that “common sense” is just not so in complex systems, and showed it is possible to formally educate people to become better system dynamics thinkers in the workplace using dynamic system models visualized in flow diagrams [Forrester61].

En contraste avec une formation sur les détails statiques que la plupart d’entre nous avons suivie, peu d’entre nous ont reçu de formation sur l’étude des systèmes dynamiques et complexes[^3] et notamment en milieu professionnel. Peut-être parce que nous avons la croyance qu’il est suffisant de s’appuyer sur le bon sens en milieu professionnel. Jay Wright Forrester a démontré que le « bon sens » n’est pas suffisant dans des systèmes complexes et qu’il est possible de former des personnes pour leur permettre de mieux appréhender les dynamiques des systèmes en milieu professionnel en utilisant notamment des diagrammes de flux [Forrester61].

Flow diagrams encompass material, financial, and information flows, stocks (variables with a quantity, such as cash or number of defects), the impact of decisions and policies, and cause-effect relations. A popular simplification is the causal loop diagram that focuses on cause-effect relationships and feedback loops in a system [Sterman00]. There are a variety of similar notations; they all show stocks (variables), causal links, and delay. In [Weinberg92] this is called the diagram of effect .

Les diagrammes de flux peuvent s’appliquer aussi bien aux flux matériels, financiers, d’informations, de stocks (n’importe quel type de stock quantitatif comme de l’argent ou des anomalies), aux conséquences des décisions et des politiques et des relations de causes à effet. Lorsque nous pensons aux diagrammes de flux, nous pensons souvent au seul diagramme de boucle causale dédié aux relations de cause à effets et aux boucles de rétroaction dans un système [Sterman00]. Il existe une grande variété d’autres diagrammes qui peuvent faire figurer les stocks (quels qu’ils soient), les liens de causalités, et les retards. Dans son ouvrage, [Weinberg92] Gerald Weinberg appelle cela un diagramme d’effet.

The First Law of Diagramming: Model to Have a Conversation

La première loi de la réalisation d’un diagramme : nous modélisons pour avoir une conversation

A tool to learn to see system dynamics is a causal loop diagram, ideally sketched on a whiteboard in a LeSS Overall Retrospective with colleagues. Before going further, here is the First Law of Diagramming

Un outil très utile pour apprendre les dynamiques des systèmes est le diagramme de boucles causales - nous vous recommandons de l’utiliser sur un tableau blanc notamment lors des Rétrospectives Globales LeSS. Mais avant d’aller plus loin, voici la première loi de réalisation d’un diagramme.

The primary value in diagrams is in the discussion while diagramming—we model to have a conversation.
La première valeur d’un diagramme c’est la discussion qui se déroule lors de la réalisation du diagramme - nous modélisons pour avoir une conversation.

When a group gets together to sketch a causal loop diagram on a whiteboard (See it is the the acts of discussing and thinking that are most important when diagramming, Valtech India.), the primary value is the conversation and shared understanding they arrive at while creating the model. Its visualization as an easy-to-see diagram is important to make concrete and unambiguous (on the whiteboard) the ideas—the mental models people have—because words alone can be fuzzy and misunderstood. But still, the diagram is secondary to what people take away: learning and a revised understanding through a discussion.

Lorsqu’un groupe se rassemble pour dessiner un diagramme de boucles causales sur un tableau blanc (« C’est l’acte de discuter et de réfléchir qui est le plus important lorsque nous dessinons », Valtech India.), la première valeur d’un diagramme c’est la conversation et la compréhension commune à laquelle les personnes arrivent lors de la création du modèle. Ce qu’il en résulte à savoir un diagramme facile à comprendre est important pour rendre les idées et les modèles mentaux concrets et non ambigües (sur le tableau blanc) parce que les mots seuls peuvent être imprécis et mal compris. Toutefois, le diagramme est secondaire par rapport avec ce que les gens repartent : ils ont appris quelque chose et ont revu leur compréhension du monde à travers une discussion.

Doing system thinking. Sketching a causal loop diagram together—modeling to have a conversation.

Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation

Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation.

Concrete modeling tip : We start by writing on sticky notes to define variables . A note might read “feature velocity” or “# defects.” We place these on a whiteboard. Then we sketch causal link lines between the sticky notes. There will be (or should be) lots of rewriting, erasing, and redrawing during the modeling session. The most meaningful outcome is understanding ; in addition, some participants will want to take a digital photo of the whiteboard sketch.

Trucs et astuces de pro pour modéliser : Nous commençons par écrire sur des petits papiers repositionnables les noms des variables, par exemple « vélocité des features » ou « nombre d’anomalies ». Nous les plaçons ensuite sur le tableau blanc. Puis nous dessinons les liens de causalités entre les papiers . Il y aura (ou il devrait y avoir) beaucoup de réécriture, d’effaçage, de redessin lors de la session de modélisation. Le résultat le plus important d’une telle session est la compréhension - il se peut qu’à l’issue de cet atelier, certains participants voudront prendre une photo du dessin du tableau blanc.

Seeing System Dynamics: Causal Loop Diagrams

Voir les dynamiques des systèmes : les diagrammes de boucles causales

Causal loop diagrams are used regularly in introductions to LeSS, to help see the dynamics of what is going on in large-scale development. It is useful to understand them for that reason alone. And more useful to you, we recommend you do these together with colleagues at a whiteboard. Model to have a conversation. When? Probably during a LeSS Overall Retrospective.

Les diagrammes de boucles causales sont souvent utilisés en introduction à LeSS pour aider à voir les dynamiques de ce qu’il se passe dans du développement à grande échelle. Il est donc utile de comprendre ce type de diagrammes pour cette seule et unique raison. Et cela s’avèrera encore plus utile pour vous, si vous le faites avec vos collègues devant un tableau blanc. Vous modélisez pour avoir une conversation. Quand ? Plus probablement lors d’une rétrospective globale LeSS.

The practical aspect of this tip is more important than may first be appreciated. It is vague and low-impact to suggest “be a systems thinker.” But if you and four colleagues get into the habit of standing together at a large whiteboard, sketching causal loop diagrams together, then there is a concrete and potentially high-impact practice that connects “be a systems thinker” with “do systems thinking.”

L’aspect pratique de cet exercice est bien plus important que ce qu’il peut paraître au premier abord. Notre conseil d’« être un pratiquant systémique » peut vous sembler vague et sans grand impact. Mais si vous et quatre de vos collègues prenez l’habitude de vous réunir devant un grand tableau blanc, en dessinant des diagrammes de boucles causales ensemble, alors vous arriverez à faire la connexion entre « être un pratiquant systémique » avec « faire de l’approche systémique ».

The following examples seem sterile when presented in a book. But imagine you were at a whiteboard with other people and the diagrams were being sketched during a lively conversation. That’s the way we suggest ‘doing’ systems thinking.

Les exemples suivants peuvent paraître stériles car présentés dans un livre. Mais imaginez-vous à côté d’un tableau blanc avec d’autres personnes dessinant ensemble des diagrammes au cours d’une conversation animée. C’est de cette manière-là que nous suggérons de ‘ faire ’ de l’approche systémique.

Notation and Examples
Notation et exemples

Causal loop diagrams contain many elements; the following common useful subset is explored through a scenario.

Les diagrammes de boucles causales contiennent beaucoup d’éléments ; les éléments suivants sont les plus communément utilisés et sont vus en détail tout au long du scénario qui va suivre

  • variables
  • causal links
  • opposite effects
  • constraints
  • goals
  • reactions; quick-fix reactions
  • interaction effects
  • extreme effects
  • delays
  • positive feedback loops
  • variables
  • liens de causalité
  • effets opposés
  • contraintes
  • objectifs
  • réactions ; réactions solutions de contournement
  • effets d’interaction
  • effets extrêmes
  • retards
  • boucles de feedback positives

The following simplified scenario is for a particular organization. It is not a generalization.

Le scénario qui suit est un scénario simplifié pour une organisation spécifique. Il ne s’agit pas d’une généralisation.

Variables—Causal loop diagrams include variables (or stocks) such as the velocity (rate of delivery) of software features and number of defects . Variables have a measurable quantity.

Les variables - Les diagrammes de boucles causales comportent des variables (ou des stocks) telle que la vélocité (taux de livraison) des features et le nombre d’anomalies. Les variables ont une quantité mesurable.

1er schéma

Causal links—An element can have an effect on another, such as if feature velocity increases, then the number of defects increase; that is, more new code, more defects.

Les liens de causalité - Un élément peut avoir un effet sur un autre, comme par exemple si la vélocité des features augmente alors le nombre d’anomalies augmente ; autrement dit, plus de code, plus d’anomalies.

2ème schéma

Now it is time to bump into Weinberg-Brook’s Law and the Causation Fallacy . It is easy to sketch a diagram; it is something else to model with insight. For example, consider the relationship between the number of developers and feature velocity.

Il est temps désormais de se jeter à corps perdu dans la loi de Weinberg-Brooks et dans la causalité fallacieuse. C’est facile de dessiner un diagramme, ça l’est moins que de modéliser en faisant preuve de clairvoyance comme par exemple, la relation entre le nombre de développeurs et la vélocité des features.

The nature of any cause-effect relationship is actually not obvious, though it is common for people to jump to conclusions such as more developers means better velocity. Adding people late in development may reduce velocity (a sub-element of “Brooks’ Law” [Brooks95]). Or, more bad programmers could really slow you down. An argument can be made that removing terrible developers can improve velocity.

Toute relation de cause à effets est par nature obscure, même si les gens ont l’habitude de sauter sur la première conclusion venue comme par exemple plus de développeurs égale plus de vélocité. Ajouter des personnes tard au cours du développement peut réduire la vélocité (il s’agit d’une composante de la « loi de Brooks » [Brooks95]). Ou, davantage de mauvais développeurs pourrait vraiment vous ralentir. Il pourrait être objecté qu’enlever des développeurs exécrables peut permettre d’améliorer la vélocité.

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-6-fr.png|frame|none|alt=|caption systems thinking-6.png]]

3ème schéma

Opposite effects—A causal link effect may be the same or opposite direction; if A goes up then B goes up, or vice versa. Opposite effect is shown with an ‘O’ on the line. Suppose defects going up puts a drag on the system, lowering the velocity of new features because people spend more time fixing or working around bugs.

Effets opposés - L’effet d’un lien de causalité peut aller dans la même direction ou dans la direction opposée. Si A monte alors B monte ou vice versa. L’effet opposé se souligne à l’aide d’un ‘0’ sur la ligne. Supposons que les anomalies ralentissent grandement le système, réduisant la vélocité des nouvelles features parce que les gens passent plus de temps à corriger ou à trouver des solutions de contournement aux anomalies.

4ème schéma

Constraints—Unless you can find people to work for free, there is a constraint on the number of developers, based upon cash supply.

Contraintes - À moins que vous ne trouviez des personnes prêtent à travailler gratuitement, il y a une contrainte sur le nombre de développeurs basé sur le budget disponible.

Constraints are not causal links. As cash supply goes up, it is not the case that the number of developers goes up.

Les contraintes ne sont pas des liens de causalité. Lorsque la montant du budget disponible augmente, ce n’est pas le cas du nombre de développeurs/

5ème schéma

Goals and Reactions–People, departments, and systems have goals, such as higher feature velocity . Goals often generate pressure for people to react (or act), with the intent of achieving the goal. But since there is Causation Fallacy and Weinberg-Brooks’ Law to contend with, people should be cautious about assuming what actions will help. Now a goal and pressure for reaction is shown:

Buts et réactions - Les personnes, les départements et les systèmes ont des buts, comme par exemple avoir une vélocité des features plus élevée. Les buts occasionnent souvent de la pression pour que les gens réagissent (ou agissent) dans l’intention de leur faire atteindre ce but. Mais étant donné qu’il y a la causalité fallacieuse et la loi de Weinberg-Brooks à laquelle il faut faire face, les gens devraient être prudents quant aux actions pertinentes à entreprendre. Voici un exemple de diagramme modélisant cela :

6ème schéma

Not only does a goal with a reward create pressure to act, but also it creates pressure to appear to be acting and achieving, due to the measurement dysfunction generated by rewards. And the measurement dysfunction can be proportional to the perceived value of the reward because people are being motivated to get a reward, not to improve the system [Austin96]. Notice how rewards can actually degrade system performance. Visually, the system dynamics may be…

Non seulement un but à atteindre avec une récompense au bout engendre une pression à agir, mais cela créé aussi une pression à faire semblant d’agir et à atteindre le but — les récompenses provoquent un dysfonctionnement des indicateurs. Le dysfonctionnement des indicateurs peut être proportionnel à la valeur perçue de la récompense parce que les personnes sont motivées pour avoir la récompense, non pour améliorer le système [Austin96]. Remarquez bien comment et de quelle manière les récompenses peuvent dégrader la performance du système. De manière visuelle, les dynamiques d’un tel système pourrait être …

7ème schéma

It is quite interesting that all these dynamics have been added by introduction of reward, and yet there is no necessary connection between the top part of this model and the bottom.

Il est assez intéressant de voir que toutes ces dynamiques ont été ajouté par l’introduction d’une récompense et qu’il n’y pas de connexion entre le haut et le bas de cette modélisation.

There is no guarantee that feature velocity has improved—or even been worked on.

Il n’y a aucune garantie que la vélocité des features s’améliore ou même que l’on y travaille.

Removing the reward system is a root-cause solution to the dysfunction. Another (lesser) surface countermeasure is the lean-thinking Go See (go see physically at the place of real work) principle and management behavior:

Enlever le système de récompense est une solution à la cause racine de ce dysfonctionnement. Une autre contremesure de surface est le principe et le comportement managériale Aller voir (aller voir physiquement sur le lieu où le travail s’effectue) de l’approche lean.

8ème schéma

Quick-fix reactions—One difficult and slow solution toward the goal of higher velocity is to hire great developers, to increase coaching and education of existing staff, and to remove terrible workers. The alternative is called a quick fix , a reaction that is hoped to achieve the goal quickly and with less effort. Sometimes a quick fix works well both in the short and long term, really strengthening the system. Sometimes not…hence, “faster is slower.” For example, people may believe that increasing the number of developers increases the feature velocity. And they may thereby hope that hiring more developers will most quickly and easily solve the velocity problem. ‘QF’ indicates the quick fix:

Solutions de contournement - Une solution payante à long terme pour atteindre une vélocité plus grande, qui n’est pas sans difficulté, consiste à : recruter de développeurs très qualifiés, faire davantage d’accompagnements et de formations, et à se séparer des moins bons éléments. L’alternative est ce que l’on appelle une solution de contournement, c’est ce que l’on met en place dans l’espoir d’atteindre l’objectif en moins de temps et avec moins d’effort. Parfois, une solution de contournement se révèle payante aussi bien dans le court terme que dans le long terme, renforçant par la-même le système. D’autres fois cela ne fonctionne pas … d’où l’expression « aller plus vite c’est aller plus lentement ». Par exemple, les gens peuvent croire qu’augmenter le nombre de développeurs permet d’augmenter la vélocité des features. Et ils peuvent par conséquent être amenés à espérer qu’en recrutant davantage de développeurs cela permettra de résoudre plus vite et plus facilement le problème de vélocité. La mention ‘SC’ sur le diagramme ci-dessous indique une solution de contournement.

9ème schéma

Interaction effects—There is the constraint of cash supply on hiring. One hard and slow solution is to get more cash. A quicker fix is to hire much cheaper developers. In this case, the level of cash supply now has an interaction effect with other causal links. Low cash tends to strengthen the hire rate of much cheaper developers when there is pressure to increase hire rates.

Effets d’interaction - La capacité à embaucher est contraint à la capacité budgétaire. Une solution de longue haleine non sans difficulté est d’obtenir davantage de budget. Une solution de contournement possible est de recruter un grand nombre de développeurs bon marché. Dans ce cas, le niveau du budget a un effet d’interaction avec les autres boucles causales. Un budget peu élevé aura tendance à renforcer le taux de développeurs bon marché si la pression pour recruter augmente.

One could simply draw an (opposite) causal link directly from cash supply to hire rate of very cheap developers , but that merely says that less cash leads to more hiring of extremely cheap developers. That is not quite what we want to say; rather, we want to show the interaction effect—that effect A influences effect B. This is done by showing a causal link entering another causal link. For example, from cash supply to the quick-fix line going into hire rate of very cheap developers :

Nous pourrions dessiner simplement un lien de causalité (opposé) de rentrée budgétaire à taux de recrutement de développeurs bon marché, mais cela voudrait simplement dire qu’avoir un budget moindre aurait pour conséquence de recruter davantage de développeurs bon marché. Mais ce n’est pas tout à fait ce que nous voulons dire ; ce que voulons montrer en fait, c’est l’effet d’interaction - c’est-à-dire qu’un effet A influence un effet B. Cela se fait en montrant un lien de causalité heurtant un autre lien de causalité, par exemple en traçant une ligne de rentrée budgétaire vers la ligne représentant la solution de contournement qui va vers taux de recrutement de développeurs bon marché.

10ème schéma

Extreme effects—We have worked with some very inexpensive developers with excellent skill and some very expensive developers that are terrible, but on average, you get what you pay for—when you hire from a large pool of very cheap labor, the average skill level is lower. In the model we want to show that the impact of hiring very cheap labor on the number of low-skilled developers is a significantly greater effect than average.

Effets extrêmes - Il nous est arrivé de travailler avec d’excellents développeurs très bon marché et avec d’autres hors de prix très nuls, mais en moyenne, vous obtenez à hauteur de ce que vous payez - lorsque vous recrutez au moins disant, le niveau moyen en terme de compétences sera plus faible. Dans le diagramme ci-dessous, nous avons voulu montrer que l’impact du recrutement de personnes bon marché en rapport avec le nombre de développeurs peu qualifiés à un impact sensiblement plus grand que la moyenne.

To show an extreme effect in the model, use a thick line:

Pour montrer un effet extrême sur un modèle, faites un trait épais comme vous pouvez voir ci-dessous :

11ème schéma

Delays—One problem in hiring in software development is the fallacy of mild programmer variance —the mistaken belief that programmer variance (in terms of productivity, code quality, etc.) is relatively small. However, programmer variance studies suggest an average of four times faster in the top versus bottom quartile [Prechelt00]. Rather significant. Also, the COCOMO model—based on large and longitudinal studies—shows that the capability of the development personnel is by far the most important factor for productivity [Boehm00]. And, on average, very weak programmers create poor-quality code (poor design) and more defects, creating another drag on the system.

Retards Un problème courant au niveau du recrutement dans un projet de développement logiciel concerne l’erreur au niveau de la variance d’un développeur moyen - autrement dit la croyance fausse que la variance d’un développeur à un autre (en terme de productivité, de qualité de code, etc.) est relativement faible. Toutefois, les études de la variance au sujet des développeurs montrent un rapport de un à 4 entre le 1er quartile et le dernier [Prechelt00]. C’est plutôt quelque chose de significatif. De même des études - en long et en large - du modèle COCOMO montrent que la capacité du développement personnel est le facteur de loin le plus important quant à la productivité [Boehm00]. Et, en moyenne, il s’avère que les développeurs peu qualifiés font du code de mauvaise qualité (mauvaise conception) et de plus d’anomalies, ceci rajoute un autre frein au système.

But the impacts of these effects are not immediately obvious. For example, it takes a relatively long time after hiring a large pool of weak programmers before the impacts of more and more bad code/design start to be felt. Similarly, the average decrease in feature velocity (because of the powerful impact of programmer variance) will not show up immediately.

Mais l’impact de ces effets ne sont pas visibles immédiatement. Par exemple, cela peut prendre un certain temps après un recrutement massif de développeurs peu qualifiés avant que les impacts négatifs ne se fassent sentir au niveau de la qualité du code ou de la conception. De manière similaire, la baisse moyenne de la vélocité des features (en raison de l’impact important de la variance des développeurs évoqué plus haut) ne se verra pas immédiatement.

To show these delayed effects in the model, use a double-line through the effect line:

Pour montrer ces effets à retardement dans le modèle, faites une double-ligne en travers de la ligne d’effet.

12ème schéma

Delay has an intriguing influence on the educational or corrective power in a system. If an impact or unintended consequence is long delayed, one does not feel the effect (pain or gain) and so does not clearly see how A influenced B, or more subtly how A influenced B influenced A .

Le retard a une influence intéressante sur le pouvoir pédagogique ou correctif sur un système. Si un impact ou une conséquence inattendue est retardé suffisamment longtemps, personne n’en voit ni l’effet (qu’il soit bénéfique ou néfaste) ni sur la façon dont A influence B ou plus subtilement comment A a influencé B qui a influencé A.

Therefore, one does not learn from or correct mistakes—in policy, management actions, tools, and so forth. Likewise, gradual improvement through the lean thinking practice of kaizen can take a long time; patience and insight are needed to see if and how things improve.

Par conséquent, personne n’apprend de ses erreurs ni n’est en capacité de les corriger - que ce soit en terme de stratégie, d’actions d’encadrement, d’outils ou de quoi que ce soit. De la même manière, l’amélioration graduelle à travers l’application d’une démarche lean kaizen, peut prendre un certain temps ; de la patience et de la perspicacité sont nécessaires pour voir si et comment les choses s’améliorent.

Positive feedback loops—Negative or positive feedback loops5 and delays are where things start to get more subtle in a system—and in understanding a system. For example, how does one become a better programmer? In part, by mentoring from great programmers and seeing lots of examples of great code. But an office with a lot of low-skill developers does not generate a lot of great code examples, nor does it attract or retain the small pool of great programmers who could act as mentors. They would rather work somewhere else.

Boucles de feedback positives - Les boucles de feedback négatives ou positives [^5] et les retards sont le point de départ pour une approche plus subtile d’un système - et de sa compréhension. Par exemple, de quelle manière une personne peut-elle devenir un meilleur développeur ? En partie, en bénéficiant du mentorat de très bons développeurs et en jetant un œil sur du très bon code. Mais il est impossible de trouver du bon code dans un endroit remplit de développeurs médiocres, il est impossible également d’y attirer ou de retenir le petit groupe de très bon développeurs qui pourraient prendre le rôle de mentors. Ils préfèrent largement aller travailler ailleurs.

Now the development group starts to enter a self-reinforcing downward spiral—a set of positive feedback loops . Fortunately, the downward trend is constrained by the supply of cash.

Ce groupe de développeurs médiocres rentrent dans un cercle vicieux en raison d’un ensemble de boucles de feedback positives. Fort heureusement, ce cercle vicieux est assujeti aux contraintes du budget.

More great programmers—who could craft great code and mentor others—leave. So there is less and less quality code to look at and to learn from. The percentage of weak programmers grows even larger and feature velocity drops further. Code becomes more messy, awkward, and duplication-riddled, so the capacity to swiftly implement features declines. Since feature velocity is dropping further, there is more pressure to hire yet more very cheap programmers. All this leads to multiple positive reinforcement loops in the system, for example:

Malheureusement de plus en plus des très bons développeurs - ceux en capacité d’élaborer du très bon code et de faire du mentorat auprès des autres développeurs - partent. Par conséquent, il y a de moins en moins de code de qualité à regarder et à partir duquel il est possible d’en tirer des enseignements. Le pourcentage de développeurs médiocres augmente de plus en plus et la vélocité au niveau des features continue à chuter. Le code devient de plus en plus brouillon, difficile, avec pleins de bouts de code dupliqués à gauche et à droite, le tout de telle manière que la capacité d’implémenter des features décline. Étant donné que la vélocité des features continue de chuter, il y a davantage de pression pour recruter des développeurs très bon marché. Tout cela conduit à de multiples boucles de renforcement positives dans le système comme l’illustre l’exemple ci-dessous :

13ème schéma

Tip : You can find positive feedback loops by finding cycles with an even number of ‘Opposite’ effect relationships. There are several examples in the model above.

Astuce : Vous pouvez trouver des boucles de feedback positives en cherchant des cycles ayant un nombre pair de relations. Vous en trouverez plusieurs exemples ci-dessus.

Conclusion
Conclusion

The example scenario is only that—an example. A causal loop diagram can visualize rich dynamics in a workplace system. These are best created by a group at a whiteboard.

Le scénario donné à titre d’exemple est uniquement cela - un exemple. Une diagramme de boucle causale permet de visualiser la richesse de la dynamique dans le système dans un milieu professionnel. La meilleure manière de modéliser un tel système est de le faire en groupe face à un tableau blanc.

Seeing Mental Models

Voir les modèles mentaux

The previous causal loop diagrams reflect people’s mental models of causation, which may be wrong. It is interesting to note that people’s models of causation are influenced by the timeliness (delay) and quality of feedback in the system.

Les précédents diagrammes de boucles causales reflètent les modèles mentaux de causalité des individus … qui peuvent s’avérer faux. Il est intéressant de remarquer que les modèles de causalité des individus sont influencés par la ponctualité (ou les retards) et la qualité des feedbacks dans le système.

The implication of “mental models” is to improve our meta-cognitive skill to see and question our own assumptions and chains of reasoning. Are we making faulty leaps of logic? It also implies when working with others to discuss (inquiring rather than abusing) the mental models of our colleagues.

Les « modèles mentaux » nous permettent d’améliorer nos compétences de méta-cognition pour voir et questionner nos propres postulats et l’enchaînement de nos raisonnements. Brûlons-nous des étapes de manière erronée ? Cette question implique aussi lorsque nous sommes en train de travailler avec des collègues de discuter avec eux (en s’enquérant plutôt qu’en reprochant) de leurs modèles mentaux.

Seeing these mental models is step one; changing them is the even harder part of step two. That art is beyond the scope of this introduction, though a successful LeSS adoption must involve changes in mindset and insight among many groups.

Voir les modèles mentaux n’est que la première étape ; les changer constitue une seconde partie bien plus difficile. Cet art est bien au-delà du sujet de cette introduction, même si une adoption réussie de LeSS implique des changements en terme d’état d’esprit et de prise de conscience au sein de très nombreuses équipes.

A tip to better see the mental models (beliefs, chains of inference, …) playing out in the system dynamics is to ask the following question during a modeling workshop and then sketch the answers. “Let’s talk about the assumptions behind this model. What do we believe or assume in terms of facts and effects that led us here?”

Une astuce pour mieux voir les modèles mentaux (croyances, échelle d’inférence, …) en jeu au niveau des dynamiques des systèmes est de poser les questions suivantes lors d’un atelier de modélisation puis de tracer les éléments de réponse au tableau blanc. « Parlons donc des hypothèses derrière ce modèle. Que croyons-nous ou tenons pour acquis en terme de faits et d’effets qui nous ont conduits ici ? »

Answers are sketched on the whiteboard model, for example:

Les éléments de réponse sont dessinés sur le tableau blanc. En voici un exemple :


Visualizing the assumptions in our heads… our mental models.

14ème schéma Visualiser les postulats présents dans nos têtes … nos modèles mentaux.

Example: The “Faster is Slower” Dynamic

Exemple : La dynamique « Aller plus vite c’est aller plus lentement »

With the vocabulary of quick fixes, delays, positive feedback loops, and mental models, it is fascinating to see that there can be a short-term apparent improvement in a variable as the result of a quick fix, but a delayed degradation of the very same variable—the “faster is slower” dynamic. This is a recurrent dynamic in the workplace and a cause of weakness. So it is worth another illustration.

Dorénavant, avec notre vocabulaire enrichi des termes de solutions de contournement, de boucles de feedback positives et de modèles mentaux, il est fascinant de voir qu’il peut y avoir un semblant d’amélioration à court terme sur une variable donnée, mais que cela entraîne en même temps une dégradation à retardement de cette même variable - d’où la dynamique « Aller plus vite c’est aller plus lentement ». Il s’agit d’une dynamique récurrente et d’une cause de vulnérabilité à terme. Voici un nouvel exemple illustrant cela :

The story of Microsoft Word and the secret developer toolbox : A classic example of the short-term ‘improving’ but long-term degrading dynamic is the story of the first release of Microsoft Word for Windows [Spolsky04]. It was released years later than desired. Why? Because managers tried to follow the original schedule and pushed developers to meet it .

Histoire de Microsoft Word et de la boîte à outils secrète du développeur : Un exemple typique d’une ‘amélioration’ à court terme mais d’une dynamique de dégradation à long terme est le récit de la première livraison de Microsoft Word sur Windows [Spolsky04]. Le logiciel a été livré avec des années de retard par rapport à la date prévue. Pourquoi ? Parce que les managers ont essayé à tout prix de suivre le calendrier de départ et ont fait pression sur les développeurs pour le respecter.

The story illustrates why wishful thinking is identified as one of the wastes in lean thinking. In this case the wishful thinking of insisting on (apparently) following a schedule, which implies the misconception or wishful thinking that development estimates are not estimates but are commitments—a common myth that propels degradation of a system.

Cette histoire illustre pourquoi cet espoir illusoire de respecter une date souhaitée est bien identifié comme une source de gâchis dans l’approche lean. Dans le cas présent l’espoir illusoire consiste à insister (du moins apparemment) à suivre le calendrier, ce qui implique une idée fausse ou illusoire que les estimations ne sont pas de simples estimations mais des promesses - un mythe classique qui pousse à la dégradation d’un système.

The next model illustrates a summary of the dynamics of what happened when the managers pushed people to evidently keep to the original schedule, and why this quick-fix reaction to slow progress appeared to make things faster in the short term but actually even slower in the long term. See the dynamic of schedule pressure and the secret toolbox. intentionally omits some deeper dynamics that are expanded and shown in See deeper dynamics of schedule pressure and the secret toolbox..

Le modèle suivant illustre un résumé des dynamiques à l’œuvre lorsque des managers poussent leurs équipes à respecter à tout prix les calendriers prévisionnels, et pourquoi cette solution de contournement qui freine pourtant l’avancement des travaux semblent les faire aller plus vite à court terme mais en réalité plus lentement à long terme. Par rapport à ce qui est décrit précédemment dans la dynamique de la pression du calendrier et la boîte à outils secrète, certaines dynamiques ont été omises intentionnellement sur ce schéma et sont visibles sur le schéma dynamiques avancées.


The dynamic of schedule pressure and the secret toolbox.

15ème schéma Dynamique de la pression sur le calendrier et de la boîte à outils secrète.

As a quick fix, the Microsoft managers exhorted, bribed (with potential rewards), and threatened the Word developers to keep to the original schedule. Consequently, the developers predictably pulled out their secret developer toolbox —the many practices related to hacking out dirty code (no tests, no reviews, ignore known defects, copy-paste programming, poor design, …) to apparently deliver a feature faster. You see, developers also have quick-fix reactions for their problems.

En solution de contournement, les managers de Microsoft ont exhorté, ont corrompu (à l’aide de primes potentielles), et ont menacé les développeurs de Word pour leur faire respecter le calendrier prévisionnel. En conséquence, les développeurs ont, de manière tout à fait prévisible, sorti leur boîte à outils secrète de développeurs - autrement dit tout un arsenal de pratiques pour pisser du code pourri (aucuns tests, aucunes revues, ignorance des anomalies connues, développement par copier-coller, mauvaise conception, …) pour développer visiblement plus vite. Vous voyez bien, les développeurs ont aussi des solutions de contournement pour régler leurs problèmes.

The tactics seemed to have worked like magic. As the managers pressured the developers, ‘features’ were delivered quicker as people used the secret toolbox, which reinforced the belief that pressuring developers helps. But this apparent acceleration actually had a delayed effect to make things slower, which is explored next. Since management did not quickly see the delayed effect of the secret toolbox, and because they believed managers should not be frequently looking in detail at the source code or themselves be master programmers, they did not learn from this dynamic.

Vu de l’extérieur, ces tactiques ont fonctionné à merveille. Au fur et à mesure que les managers mettaient la pression sur les développeurs, les ‘features’ étaient développées de plus en plus vite grâce à l’utilisation de la boîte à outils secrète, ce qui a renforcé la croyance en quoi mettre la pression sur les développeurs était quelque chose d’utile. Mais cette apparente accélération a eu en fait un effet à retardement qui a rendu les choses plus lentes (c’est ce que nous allons voir par la suite). Étant donné que le management n’a pas été assez rapide à voir l’effet à retardement de la boîte à outils, et parce que les managers pensent qu’ils n’ont pas besoin d’aller regarder fréquemment en détails le code source ou qu’ils n’ont pas besoin d’être eux-mêmes des développeurs très expérimentés, ils n’ont rien appris de cette dynamique.

A closer exploration of the system dynamics shows why things went slower in the long term and why the first Word for Windows release was years later than desired, illustrated in this model…

Le schéma ci-dessous illustre l’examen approfondie des dynamiques des systèmes montrant pourquoi les choses sont allées plus lentement à long terme et pourquoi le tout premier Word pour Windows a été livré des années en retard par rapport à la date souhaitée …

systems thinking-19.png Some deeper dynamics of schedule pressure and the secret toolbox.

16ème schéma Dynamiques avancées de la pression sur le calendrier et de la boîte à outils secrètes.

Naturally, lots of dirty code eventually slowed things down. More subtly, developers would ignore the bug list of ever-increasing open defects to—instead—generate new features. This led to a long delay between the creation of a defect and its correction. It turns out that this significantly increases variability and time to fix a defect because of the compounding negative effect of a long-lived bug (for example, due to workarounds and coupling) and because developers have long forgotten the detailed context of code related to the defect and therefore need to slowly rediscover that context—with more and more dirty confusing code surrounding them.

Naturellement, avoir une grande quantité de code de mauvaise qualité ralentie les choses. De manière beaucoup plus subtile, les développeurs ont ignoré la liste croissante d’anomalies pour privilégier la production de nouvelles features. Cela a eu pour conséquence d’avoir un délai important entre la déclaration d’une anomalie et sa correction. Il s’avère que cela a fait augmenter de manière significative la variabilité et le temps nécessaire pour corriger une anomalie en raison des effets cumulatifs négatifs liée à la nature même d’une vieille anomalie (par exemple avec la mise en place des solutions de contournement et des couplages existants entre les fonctionnalités), de l’oubli du contexte détaillé par les développeurs en relation avec l’anomalie, ces derniers mettant par conséquent plus de temps à le redécouvrir, de l’accumulation continue de code de mauvaise qualité dans le même temps.

The astute reader may also notice the several positive feedback loops that reinforce the degradation cycle; this is one reason the product was years later than intended.

Le lecteur avisé remarquera également plusieurs boucles causales positives renforçant le cycle de dégradation ; il s’agit de l’une des raisons expliquant le retard pris sur plusieurs années pour livrer le produit.

Solution? The lean thinking Stop and Fix and Go See principles. First , rather than trying to go faster when there are problems, manager-teachers encourage people to go slower and help them learn to see system dynamics and root causes, and to fix these—to improve the system of development. By going slower, Toyota—the masters of lean thinking—has become one of the fastest companies around. Second , for managers to go see at the real place of work to learn what is going on. The “real place” in software development is the code, which suggests that first-level managers are master programmers who are frequently evaluating the code.

Une solution ? L’approche lean avec les principes Arrêter et corriger et Aller voir. Premièrement, plutôt que d’essayer d’aller plus vite lorsqu’il y a des problèmes, des managers-formateurs encouragent les gens à aller plus lentement et à les inciter à apprendre les dynamiques des systèmes, les causes racines et à les corriger pour améliorer le système du développement. En allant plus lentement, Toyota - les maîtres de l’approche lean - est devenue l’une des entreprises les rapides du monde. _Deuxièmement, les managers doivent aller voir ce qui se passe sur le vrai lieu de travail pour apprendre ce qu’il se passe. Le « vrai lieu » dans le développement logiciel c’est le code, ce qui implique que les managers de proximité sont des développeurs expérimentés qui évalueront le code fréquemment.

Microsoft people did not reflect on the situation until after release. When they did finally hold a retrospective, it led to a zero-defects policy, meaning that the first priority was to fix known bugs in the code under development—to drive down to zero the open-defects list before writing more new-feature code.

Les personnes de chez Microsoft n’ont pas réfléchi sur la situation que bien après la livraison. Lorsqu’ils ont fini par faire une rétrospective, cela a amené à une politique du zéro défaut, cela signifie que la première priorité était de corriger les anomalies connues dans le code en cours de développement afin d’aller vers du zéro anomalie ouverte dans la liste des anomalies avant d’écrire du code pour une nouvelle feature.

Seeing (and Hearing) Local Optimization

Voir (et entendre) l’optimisation locale

“Everyone is doing their best yet overall systems throughput is degrading. How can that be?” This is the paradox of local optimization —when a person or departmental decision maker optimizes for the local view or self-interest. The party making the decision frequently believes they are making the best decision , but because ‘best’ is a local optimization, in fact it sub-optimizes overall system throughput. This is a result of “silo mentality,” misunderstanding, fear, limited information, delayed feedback, ignorance, careerism, avarice, and other common organizational learning disorders .

« Chacun fait de son mieux, mais malgré tout le flux de production du système se dégrade. Comment cela est-il possible ? ». Il s’agit du paradoxe de l’optimisation locale - autrement dit c’est lorsqu’une personne à titre individuel ou un responsable de département prend une décision d’un point de vue local ou dans son propre intérêt. Les personnes prenant ce type de décision croient fréquemment qu’ils prennent la meilleure décision, mais parce que ‘meilleure’ est ici synonyme d’optimisation locale, cela a pour résultat une sous-optimisation globale du flux du système. Ceci est le résultat d’une « mentalité de silo », d’incompréhension, de peur, de restrictions d’informations, de feedbacks à retardement, d’ignorance, de carriérisme, d’avarice et de bien d’autres dysfonctionnements d’apprentissages organisationnels.

A small product group of 30 people does not have the time or money to engage in much nonsense or waste. But large companies, with large product groups, centralized process and tool groups, a centralized “project management office,” and so forth, seem to have raised local optimization and waste to an art form. Government bureaucracies are the quintessential example, of course. As such, when you serve as a guide in large-scale agile adoption, seeing (or hearing ) and dealing with local optimization is singularly vital.

Une petite équipe produit de 30 personnes n’a ni temps ni l’argent pour s’engager dans ce genre de non-sens ou de gâchis. Mais les grandes entreprises avec de grands groupes produit, des processus centralisés et des groupes outils, un « bureau de gestion de projet » centralisé, et ainsi de suite, semblent avoir élevé l’optimisation locale et le gâchis à une forme d’art. Les bureaucraties gouvernementales en sont bien sûr la quintessence. En conséquence, lorsque vous servez de guide dans une adoption agile à grande échelle, voir (ou entendre) et s’occuper de l’optimisation locale est tout simplement quelque chose de vital.

For example, the legal and corporate security departments put in place a policy that seems terribly important from their perspective. In the aim of preventing loss of intellectual property (IP), the legal department decrees “no one shall put any information on the walls.” Or, in response to cost-cutting pressure, the facilities management says, “It is important to ensure our walls are not dirty or damaged.” And thus they shut down a practice in lean thinking, visual management (which is usually done on walls), and they inhibit a well-known innovation practice, group whiteboard work. The lawyers may succeed in reducing loss of IP (actually, that is questionable), and the facilities people will succeed in keeping the walls clean—at the cost of inhibiting the product development group from innovating and collaborating. Finally, the company falls behind with less and less IP even worth protecting because tools for innovation and delivering fast have been disallowed, but the lawyers have successfully fulfilled their mandate from the executive team to “ensure our IP is protected.” And the furniture police have clear walls. They have done their best .

Par exemple, les départements juridiques et sécurité mettent en place des politiques qui leurs semblent très importantes de leurs points de vue. Dans l’objectif de prévenir la perte de propriété intellectuelle, le département juridique peut décréter « il est interdit d’afficher tout type d’information sur les murs. ». Or, le département des immeubles soumis de son côté, à une pression de politique de réductions de coûts peut surenchérir en disant : « Il est important de s’assurer que nos murs ne soient ni sales ni abîmés ». Et ainsi s’arrête le management visuel qui est l’une des pratiques de l’approche lean (le management visuel se faisant habituellement sur les murs), et ils inhibent également une pratique d’innovation bien connue à savoir le travail de groupe devant un tableau blanc. Les juristes réussiront peut être à réduire la perte de propriété intellectuelle (ce qui en réalité devrait poser question), et les gens des immeubles réussiront à garder leurs murs propres - mais au prix d’inhiber le groupe de développement produit dans sa capacité d’innover et de collaborer. Finalement, l’entreprise se laissera distancer par la concurrence avec de moins en moins de propriété intellectuelle valant la peine d’être défendue parce que les outils permettant l’innovation et de livrer rapidement ont été bannis, mais les juristes auront rempli leur mandat vis-à-vis de la direction de « s’assurer que la propriété intellectuelle est protégée ». Et la police de la logistique aura nettoyé les murs. Ils ont fait de leur mieux.

The following is a real e-mail quote from the FURNITURE POLICE in one organization that dissallowed visual management on the walls. Can you identify the local optimizations and mental models driving this?

Ce qui suit est extrait d’un vrai message électronique de la POLICE DE LA LOGISTIQUE dans une organisation qui a banni le management visuel sur les murs. Pouvez-vous identifier les optimisations locales et les modèles mentaux qui sont derrière tout ça ?

Individual work cubic partition can be personalized. But things obvious higher than the partition or harming the office environment’s harmony are restricted.
_Les bureaux à cloisons peuvent être personnalisés. Mais tout ce qui visible au-dessus de la cloison ou qui perturbe l’harmonie de l’environnement de bureau est interdite.

We also see local optimization in centralized groups that make software tool choices for others. The common mindset is to choose a tool that is best at reducing some supposed cost (curiously, these groups seldom recommend free open source tools) or best at doing something complicated or best for the work of one specialized worker role (even though everybody has to use the tool), rather than maximizing the global goal of faster system throughput of value to customers.

Nous constatons aussi des optimisations locales dans les groupes centralisés dont le rôle est de choisir les logiciels pour les autres personnes de l’entreprise. La croyance la plus répandue que cette démarche est qu’il s’agit de ce qu’il y a de mieux pour réduire les coûts d’achats (curieusement ces mêmes groupes recommandent rarement les logiciels libres gratuits) ou ce qu’il y a de mieux pour accomplir une tâche compliquée ou ce qu’il y a de mieux pour l’accomplissement du travail d’un seul type de travailleur (même si tout le monde est censé devoir utiliser l’outil), plutôt que de maximiser l’objectif de l’entreprise qui est d’avoir un système de flux de production de la valeur plus rapide pour les clients.

In large-scale adoption of Scrum or agile principles, most of the “Yes, but …” issues that are raised are examples of local optimization, such as, “Yes, but…what about management reporting?” or more generally, “Yes, but…what about <special case="">?” Then, policies and practices are twisted around, serving the goal of reporting or some other secondary aim rather than the primary goal of optimizing for fast value throughput. Sometimes we see local optimization for the extreme or rare case . For example, a person responsible for making a centralized tool choice for the enterprise presents a scenario for a complex or rare case of use, and then chooses the tool that fits that, sub-optimizing for a 5 percent case instead of optimizing for ease and speed for the 95 percent case.</special>

Dans les adoptions de Scrum ou des principes agiles à grande échelle, la plupart des problématiques de type « Oui, mais … » qui sont soulevées sont des exemples de sous-optimisations, comme par exemple « Oui, mais … qu’en est-il des comptes-rendus auprès du management ? » ou encore de manière plus générale « * Oui, mais … qu’en est-il de … * ? ». Alors, les principes et les pratiques sont dévoyés, pour servir soit l’objectif de rendre compte soit n’importe quel autre objectif secondaire plutôt que suivre l’objectif d’optimiser le flux de valeur produite. De temps en temps, nous voyons des optimisations locales dans certains cas rares ou extrêmes. Par exemple, une entreprise doit choisir un outil centralisé répondant à un certain nombre de cas d’utilisations possibles dont un cas extrêmement rare ou complexe, la personne, en charge de faire ce choix, choisit un outil correspondant à un cas unique d’utilisation, sous-optimisant ainsi l’ensemble du système pour un cas représentant uniquement 5% des cas d’utilisation au lieu de l’optimiser pour la majorité des 95% des autres cas d’utilisations.

Other local optimizations are due to ignorance of new ways of working. This is especially common in large-scale product groups. For example, we once helped a large networking product group in Europe adopt Scrum and the practice of continuous integration (CI) combined with a CI system that continually integrated, built, and automatically tested the product. After some time, an outside traditional manager inspected what was going on, and recommended the integration practices should be changed—because there was no written integration plan for how a human integration manager should manually integrate all the software, and of course, there was no integration manager. They wanted to ‘optimize’ around the work of an integration manager that was no longer needed. They could not see that their entire old-fashioned model of work had been eliminated with CI. This story repeats in all the departments of a large established product: local optimization around the existing ways of work, such as manual test, a separate architecture department, component teams, and so on. A coach working to introduce large-scale Scrum at the enterprise level has a mountain of similar local optimization thinking to deal with.

D’autres optimisations locales sont dues, quant à elles, à l’ignorance des nouvelles manières de travailler. C’est quelque chose de très répandue et tout spécialement dans les groupes produit à grande échelle. Par exemple, un jour nous avons aidé un groupe produit distribué à travers l’Europe à adopter d’une part Scrum et d’autre part la pratique de l’intégration continue (CI) le tout sous la forme d’un système d’intégration continue dédié intégrant, compilant, testant automatiquement de manière continue le produit. Après quelques temps, un manager, que l’on pourrait qualifier de traditionnel, extérieur au groupe est venu inspecter ce qu’il se passait. Celui-ci a recommandé que les pratiques d’intégration devraient être changées en raison de l’absence de schéma d’intégration global permettant à un responsable d’intégration de faire manuellement l’intégration de l’ensemble du logiciel ; une absence de schéma pour la bonne raison qu’il n’y avait plus besoin de responsable d’intégration au sein de l’organisation. Il voulait ‘optimiser’ le travail d’un responsable d’intégration qui n’existait plus. Il était dans l’impossibilité de voir que la totalité de l’ancienne manière de faire les choses avait disparu avec l’intégration continue. Cette histoire se répéta dans l’ensemble des départements du groupe produit : il y a avait des optimisations locales partout autour des façons de faire existantes, tels que les tests manuels, le département d’architecture séparé des équipes, les équipes composants, etc. N’importe quel coach dont la tâche consistait à introduire Scrum à grande échelle au niveau de l’organisation avait une montagne d’optimisations locales à penser à gérer.

In lean thinking and agile methods, the focus is on global systems goals: Deliver value fast with high quality and morale—global optimization . Try to consider decisions in light of this goal. To develop an “optimize the whole” culture, challenge all decisions and policies with the question:

Dans l’approche lean et dans les méthodes agiles, l’accent est mis sur les objectifs du système dans sa globalité : livrer de la valeur de grande qualité au plus vite tout en gardant le moral des équipes au plus haut - autrement dit une optimisation globale. Essayer de reconsidérer vos décisions à la lumière de cet objectif. Pour développer une culture de « l’optimisation du tout », remettez donc en cause toutes les décisions et les règles avec la question suivante :

Does this decision or policy focus on delivering value to the external customer fast, or does it focus on the interests of a department, person, internal policy/practice, or rare case?
** Est-ce que cette décision ou cette règle se focalise-t-elle sur livrer de la valeur au client externe au plus vite, ou se focalise-t-elle sur les intérêts d’un département, d’une personne, d’une pratique/règle interne, ou d’un cas rarissime ?**

In LeSS, the Product Owner is responsible for choosing high-value goals that could lead to potentially shippable product (at the end of the Sprint) and that maximize the desired impacts and that delight the customer, while maintaining a sustainable pace and high engineering quality. That explicit goal is meant to orient the system toward global rather than local optimization.

Dans LeSS, le Product Owner est responsable pour choisir ces objectifs à haute valeur qui pourrait mener à un produit potentiellement livrable (à la fin du Sprint) maximisant les impacts souhaités et réjouissant le client tout en maintenant un rythme soutenable et une haute qualité d’ingénierie. Cet objectif explicite est destiné à orienter le système vers son optimisation globale plutôt que vers une optimisation qui ne serait que locale.

Conclusion

Conclusion

In addition to becoming a systems thinker yourself, encourage others to learn more about this topic. We suggest you to try getting together at a whiteboard with colleagues to sketch a causal loop diagram, so that being systems thinkers and doing systems thinking are connected at the workplace.

En plus de devenir un pratiquant de l’approche systémique vous-même, encouragez donc les autres à en apprendre plus sur ce sujet. Nous vous suggérons d’essayer de rassembler quelques-uns de vos collègues autour d’un tableau blanc et d’y dessiner des diagrammes de boucles causales, afin que les architectes des systèmes et les pratiquants de l’approche systémique soient réunis en un seul endroit.

<figure> group%20cld%20modeling.jpg </figure> [[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-20-fr.png|frame|none|alt=|caption systems thinking-20.png]]

<figcaption> Doing system thinking. Sketching a causal loop diagram together—modeling to have a conversation. </figcaption> Séance d’approche systémique. Réalisation d’un diagramme de boucle cause à plusieurs mains dans l’objectif d’avoir une conversation.

Recommended Readings

Lectures recommandées

  • W. Edwards Deming’s Out of the Crisis is a master work by arguably the most well-known systems thinker and quality expert. It opens with the modest goal, “The aim of this book is transformation of the style of American management… It requires a whole new structure, from foundation upward.” Deming also advocates the System of Profound Knowledge in which managers (1) appreciate there is a system , (2) understand common-cause and special-cause variation (queueing theory is related to variation), (3) understand limitations of knowledge and reasoning mistakes, and (4) know credible psychology and social research results so that behavior- or motivation-related policies are not based on “common sense.” The core of the book centers around his famous 14 Points for Management , including (for example), “Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership .”
  • Hors de la Crise de W. Edwards Deming est un ouvrage de référence par, sans conteste, le plus connu des penseurs systémiques et des experts sur la qualité. Cet ouvrage commence par un objectif modeste : « l’objectif de ce livre est la transformation du style du management américain … ce qui exige une toute nouvelle structure de fonds en combles. ». Deming prône un Système de connaissances approfondies dans lequel les managers (1) reconnaissent qu’il y a un système, (2) qu’ils sont en mesure de comprendre les facteurs les plus répandus et les facteurs spéciaux de variations au sein du système (la théorie des files d’attente est liée à ce phénomène de variation), (3) qu’ils sont en mesure de comprendre que les connaissances sont limitées et qu’il y a des erreurs de raisonnements, et (4) que la psychologie et les recherches en sciences sociales jouent des rôles tout à fait crédibles dans l’objectif de comprendre que les règles régissants les comportements ou en lien avec la motivation des individus ne soient pas basés sur le seul « bon sens ». Le cœur de l’ouvrage tourne autour des célèbres 14 points pour le management, y compris par exemple « Éliminer le management par les objectifs. Éliminer le management par les nombres, par les objectifs par les nombres. Y substituer le leadership»
  • Jay Forrester’s Industrial Dynamics is the classic text on system dynamics—well written and insightful. Although written in the early 1960s, it is as relevant today as when published. It goes beyond cause-effect modeling to also model the flow and inventories of information, money, and material in systems. The book includes formal mathematical modeling but this is not obligatory to appreciate system dynamics.
  • Industrial Dynamics de Jay Forrester est un classique du genre sur les dynamiques des systèmes - très bien écrit et très instructif. Même si cet ouvrage a été écrit au début des années 1960, il est toujours aussi pertinent aujourd’hui. Il va au-delà de la modélisation des causes à effets pour modéliser également le flux et les stocks d’informations, d’argent et de matériaux au sein d’un système. Le livre contient également une modélisation mathématique formelle de ces dynamiques, toutefois la lecture de cette dernière reste facultative quant à apprécier la qualité de l’ouvrage.
  • Weinberg’s Quality Software Management: Systems Thinking and An Introduction to General Systems Thinking are worthwhile. Written from the perspective of an experienced consultant in systems development.
  • Les ouvrages Quality Software Management: Systems Thinking et An Introduction to General Systems Thinking de Gerald Weinberg sont intéressants. Il sont écrits du point de vue d’un consultant expérimenté en développement de systèmes.
  • Senge’s The Fifth Discipline is a classic that advocates the need for leadership to apply systems thinking (it is the fifth discipline) and other key disciplines for a great, sustainable enterpise. The others include leaders with (1) personal mastery and (2) reflection on their beliefs and faulty reasoning, the (3) definition and communication of a meaningful shared vision, and (4) the ability of teams to learn. We recommend ignoring—at least during the first few years of practice—the ‘archetypes’ notion presented in the book. It was well meant as a learning aid but has been observed to distract and intimidate people from learning and applying basic system dynamics modeling. The ‘archetypes’ are not part of original system dynamics.

La cinquième discipline est un autre classique du genre qui prône que l’encadrement d’une entreprise devrait appliquer l’approche systémique (autrement dit la cinquième discipline) ainsi que d’autres disciplines-clés toutes aussi importantes en vue d’obtenir une entreprise durable. Ces autres disciplines que les dirigeants devraient appliquer sont (1) une maîtrise personnelle des aspirations, (2) une réflexion sur leurs propres croyances et raisonnements erronés, (3) la définition et la communication d’une vision partagée ayant du sens, et (4) la capacité des équipes à apprendre. Nous vous recommandons d’ignorer - du moins dans un premier temps pendant vos premières années de pratiques - le concept d’archétypes présenté dans le livre. Ce concept avait pour but d’être une aide à l’apprentissage de la cinquième discipline mais nous avons observé qu’il était soit une source de distraction soit qu’il intimidait les lecteurs quant à leur apprentissage et à l’application de la modélisation des dynamiques des systèmes. Les ‘archetypes’ ne font pas partie à l’origine des dynamiques des systèmes.

  • The organizational-learning writings from Argyris, Putnam, McLain, and Schön. Important concepts include double-loop learning and high-advocacy/high-inquiry dialogue. Classic works include Action Science and Organizational Learning.
  • Les écrits d’Argyris, Outnam, McLain et Schön sur les apprentissages organisationnels comme Action Science et Organizational Learning abordent des concepts importants tels que la double-boucle apprenante et le dialogue grand-plaidoyer/grand-réquisitoire.
  • The publications and resources available through the Society for Organizational Learning.
  • Les publications et les ressources de la Society for Organizational Learning](https://www.solonline.org/).



Notes:

  1. La cinquième discipline écrit par Senge sur l’approche systémique et les organisations apprenantes a été nommé "l’un des livres les plus novateurs sur le management de ces 75 dernières années" par la Harvard Business Review. [Senge94].
  2. Une autre raison : croire que plus de contrôle est possible qu’il ne l’est en réalité. La science de la complexité suggère qu’il existe des limites en termes de prédiction et de contrôle des systèmes sociaux semi-chaotiques [Stacey07]. C’est une énorme boîte de Pandore qui restera close dans ce livre.
  1. Macro économie, psychologie, sociologie et biologie sont des exemples d’exceptions parmi d’autres
  2. ‘Basique’ ne signifie pas trivial ou facile à résoudre. Par exemple, les problématiques de ‘motivation’ et de ‘qualité’ sont des problématiques basiques mais elles ne sont pas faciles à résoudre.
  3. Les boucles de feedback sont parfois utilisées dans ce livre dans le sens littéral du terme, plutôt dans le sens des dynamiques des systèmes