« LeSS - Approche systémique » : différence entre les versions

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.

[[File:https://less.works/img/systems-thinking/xgroup,P20cld,P20modeling.jpg.pagespeed.ic.lirKMzwWbD.webp|frame|none|alt=|caption group%20cld%20modeling.jpg]]

''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.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-4.png.pagespeed.ic.WpO9GKmuZP.webp|frame|none|alt=|caption systems thinking-4.png]]

'''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.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-5.png.pagespeed.ic.oPRro2SqND.webp|frame|none|alt=|caption systems thinking-5.png]]

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.''

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

'''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.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-7.png.pagespeed.ic.DPGMJyX2Qf.webp|frame|none|alt=|caption systems thinking-7.png]]

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

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-8.png.pagespeed.ic.gbgAIK-IsZ.webp|frame|none|alt=|caption systems thinking-8.png]]

'''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:

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-9.png.pagespeed.ic.yVcHbh4_-i.webp|frame|none|alt=|caption systems thinking-9.png]]

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 [http://www.amazon.com/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ref=sr_1_1?ie=UTF8&qid=1413596674&sr=8-1&keywords=measuring+and+managing+performance+in+organizations [Austin96]]. Notice how rewards can actually degrade system performance. Visually, the system dynamics may be…

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-10.png.pagespeed.ic.39CLFp-g_9.webp|frame|none|alt=|caption systems thinking-10.png]]

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.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-11.png.pagespeed.ic.NU8SjnJkUY.webp|frame|none|alt=|caption systems thinking-11.png]]

'''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:

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-12.png.pagespeed.ic.x8IJWKprUx.webp|frame|none|alt=|caption systems thinking-12.png]]

'''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.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-13.png.pagespeed.ic.LvAE8ewRFJ.webp|frame|none|alt=|caption systems thinking-13.png]]

'''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.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-14.png.pagespeed.ic.JYkqz8Qe24.webp|frame|none|alt=|caption systems thinking-14.png]]

'''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 [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [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 [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. And, on average, very weak programmers create poor-quality code (poor design) and more defects, creating another drag on the system.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-15.png.pagespeed.ic.0fwliLJm6G.webp|frame|none|alt=|caption systems thinking-15.png]]

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'' .

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-16.png.pagespeed.ic.ONFuUmJHSE.webp|frame|none|alt=|caption systems thinking-16.png]]

''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.

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

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-17.png.pagespeed.ic.5UIqBnJfK1.webp|frame|none|alt=|caption systems thinking-17.png]]

=== Example: The “Faster is Slower” Dynamic ===

[https://less.works/less/principles/systems-thinking.html#figure-1 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.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-18.png.pagespeed.ic.A7OSuu755I.webp|frame|none|alt=|caption systems thinking-18.png]]

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.

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 …

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-19.png.pagespeed.ic.D24dvGHzfu.webp|systems thinking-19.png]]

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.