Systems Thinking

“Peu importe ce que nous faisons, le nombre de défauts dans notre backlog reste sensiblement le même,” nous a dit un manager ; cela pour un produit de 15 MSLOC en C et en C++ avec plusieurs centaines de développeurs sur lequel nous travaillions. Que se passe-t-il ? La pensée systémique peut aider. Dans des petits groupes les forces en jeu sont découvertes plus rapidement et comprises informellement, mais dans de grands développements produit—ou n’importe quel grand système—c’est difficile. Gerry Weinberg souligne deux facteurs décisifs dans cette situation :

Loi de Weinberg-Brooks: Il y a d’avantage de projets logiciels qui sont allés de travers par la faute des actions prises par le management, elles-mêmes basées sur des modèles système incorrects que toutes les autres raisons combinées.

Erreur de causalité: Chaque effet possède une cause… et nous pouvons dire laquelle cause quoi. [Weinberg92]

Tout cela reflète l’impact de nos modèles mentaux sur le système, un sujet que nous allons reprendre plus loin dans cette section.

Les problèmes découlant des modèles mentaux et des hypothèses sont une question. Une autre est que l’adoption à grande échelle de Scrum, de la pensée Lean, et des principes agiles n’est pas restreint au groupe de développement. Cela heurte la gestion des produits, le budget, le test beta, le lancement, et les politiques de gouvernance et de Ressources Humaines. En conséquence, dans une adoption de l’agile à grande échelle, il est utile de pouvoir être ensemble entre collègues et de réfléchir efficacement sur les modèles mentaux, les relations causales, les boucles de rétroaction, et les mécanismes de contrôle (ou d’illusions de contrôle) dans un grand système qui est sur le point d’être fortement perturbé. La pensée systémique est l’un de ces outils de résonnement.

En 1958, la Harvard Business Review a publié “La dynamique industrielle : une percée majeure pour les décideurs,” un article de référence de Jay Forrester, professeur à la MIT Sloan School. Cet article encourageait le mouvement de la pensée systémique dans l’enseignement, et la MIT Sloan School of Management est devenue connue pour l’enseignement des dynamiques systémiques . Les dynamiques systémiques sont parfois considérées comme un synonyme de la pensée systémique , quoique cette dernière soit une expression plus générale.

Le MIT a aussi attiré d’autres chercheurs orienté sur les dynamiques systémiques comme Peter Senge.¹

En cohérence avec la Loi de Weinberg-Brook, les recherches de Forrester ont montré que les décisionnaires à qui on a donné les modèles dynamiques d’un système métier puis demandé d’améliorer leur performance en sortie, en général les rendaient pires [SKRRS94]. Le constat fut que la plupart des personnes avaient un piètre jugement sur la manière d’améliorer fondamentalement des systèmes, en général par l’application d’un “bon sens” incorrect et de ‘solutions’ rapides qui ne créent pas d’améliorations systémiques durables.

Pourquoi le comportement de grands groupes de développement (un système) n’est-il pas compris ni guidé habilement ? La réponse réside en partie dans le comportement des systèmes stochastiques avec leurs queues et leurs variabilités, tels qu’étudié dans le principe LeSS de Théorie des queues. Et la même réponse se trouve dans la théorie du contrôle : La plupart des systèmes d’intérêt—comme un groupe de développement produit—ont des boucles de rétroactions positives et négatives complexes ainsi que des comportements non-linéaires. Le comportement de ces systèmes défie notre instinct primaire. Et puis il y a la question mineure des personnes.

En résumé, les raisons pour ne pas être habile à sonder ou guider un gros système incluent (mais ne sont pas limitées à) :

• le manque de connaissance sur les dynamiques des systèmes, les boucles de rétroaction, le comportement des systèmes non-linéaires, les conséquences non désirées dans les systèmes de travail
• ne pas comprendre les causes racines des problèmes (et comment les trouver)
  • les causes, et non la cause; en pensée systémique on voit qu’il y a des causes multiples, indirectes, et dynamiques aux problèmes
• ne pas savoir si et pourquoi une solution rapide ou des décisions restreintes au département local ont dégradé la performance globale de production.
  
  
  
  

Pour faire court, ne pas être des penseurs système.²

Ces raisons sont corrélatives à l’intersection du management et de l’adoption à grande échelle des principes lean et agile. L’équipe de direction fait partie du système perturbé ; s’ils n’appliquent pas la pensée systémique, ils peuvent vraiment le perturber—et pas de la bonne façon !

Comme résumé de l’essentiel de la pensée systémique, nous aimons les 11 ‘lois’ décrites dans La Cinquième Discipline:

• Les problèmes d’aujourd’hui proviennent des ‘solutions’ d’hier.
• Plus vous poussez dans un sens, plus le système pousse dans l’autre.
• Les comportements s’améliorent avant d’empirer.
• La solution de facilité vous ramène au problème de départ.
• Le remède peut être pire que le mal.
• Qui va plus lentement va plus vite.
• La cause et l’effet ne sont pas étroitement liés dans le temps et l’espace.
• De petits changements peuvent provoquer de grands résultats…mais les domaines à plus fort effet de levier sont souvent les moins évidents.
• Vous pouvez avoir le beurre et l’argent du beurre—mais pas en même temps.
• Un éléphant coupé en deux ne fait pas deux petits éléphants.
• Les reproches ne sont pas de mise.

Le motto interne de Toyota est “Bonne pensée, bons produits.” La pensée systémique est un ensemble d’outils de pensée pour aider…

• voir les dynamiques des systémes—une organisation de développement est un système de personnes et de règles avec des boucles de rétroaction subtiles et des conséquences inattendues
  • nous pouvons apprendre à voir et ainsi à améliorer le système avec des schémas de causalité créés lors d’un atelier
• voir les modèles mentaux—Une des raisons derrière les décisions sous-optimales est une hypothèse erronée et un raisonnement défectueux
  • faire des schémas de causalité et rechercher les Cinq Pourquoi les mettent en évidence
• voir l’optimisation locale—une autre source de décisions non-optimales provient de l’optimisation locale , prendre la ‘meilleure’ décision du point d’une personne ou d’un département, plutôt qu’une optimisation globale pour l’objectif au niveau des systèmes lean de fournir de la valeur rapidement avec une haute qualié et un moral élevé .
  
  
  
  

Cette introduction est organisée autour des domaines suivants en pensée systémique : Apprendre à voir (1) les dynamiques systémique , (2) les modèles mentaux , (3) les causes racines , and (4) l’optimisation locale .

Voir les Dynamiques Système : Introduction

Complexité Staticque contre Dynamique

Beaucoup d’entre nous, en particulier dans le domaine de l’ingénierie et de la finance, sont éduqués pour maîtriser la complexité des détails statiques—apprendre à analyser et gérer l’information (besoins, analyse financière , …), décomposer des structures complexes en de plus simples, et ainsi de suite. C’est-à-dire la complexité d’une nature statique, d’information ou structurelle.

Pourquoi les grands systèmes logiciels ont tendance à se dégrader, avec de plus en plus de temps consacrés aux défauts? ? Que pourrait-il se passer si les Etats-Unis invahissaient l’Iraq? Voir les dynamiques derrière ces questions requière l’analyse de la complexité des dynamiques .

Contrairement à l’enseignement aux détails statiques, bon nombre d’entre nous n’ont pas reçu de formation formelle à l’analyse de la complexité des dynamiques³, en particulier celles du lieu de travail. Peut-être existe-t-il une conviction qu’il suffit de s’appuyer sur le bon sens dans le milieu de travail. Forrester a démontré que le “bon sens” n’est juste pas présent dans les systèmes complexes, et a montré quil est possible de former effectivement les gens à devenir de meilleurs penseurs des dynamiques systémiques sur le lieu de travail en utilisant des modèles de systèmes dynamiques visualisés en diagrammes de flux [Forrester61].

Les diagrammes de flux englobent les flux matériels, financiers et d’information, les stocks (variables avec une quantité, comme l’argent comptant ou le nombre de défauts), l’impact des décisions et des politiques et les relations de cause à effet. Une simplification classique est le diagramme de causalité qui se focalise sur les relations causes-effets et les boucles de rétroaction dans un systéme [Sterman00]. Il existe une variété de notations similaires; elles montrent toutes des stocks (variables), des liens causaux, et des délais. Dans [Weinberg92], c’est appelé the diagramme d’effet .

La première Loi du Diagramme : Modéliser pour avoir une Conversation

Un outil pour apprendre à voir les dynamiques système est un diagramme de causalité, idéalement desinné sur un tableau blanc lors d’une Rétrospective Globale LeSS avec ses collègues. Avant d’aller plus loin, voici la Première Loi du Diagramme

La première valeur des diagrammes est dans la discussion pendant qu’on le trace—nous modélisons pous avoir une conversation.

Lorsqu’un groupe se rassemble pour esquisser un diagramme de causalité sur un tableau blanc (Remarquez que ce sont ces actes de discuster et de penser qui sont les plus importants quand on trace des diagrammes, Valtech India.), la principale valeur est la conversation et la compréhension partagée à laquelle ils arrivent en créant le modèle. Sa visualisation comme diagramme facile à voir est importante pour rendre concrètes et sans ambiguïté (sur le tableau blanc) les idées—les modèles mentaux que les gens ont—parce que les mots peuvent être flous et mal compris. Mais encore, le schéma est secondaire à ce que les gens conservent: l’apprentissage et une compréhension révisée à travers une discussion.

Astuce concrete de modélisation : Nous commencons par écrire sur des notes adhésives pour définir les variables . On pourrait lire sur une note “vélocité fonctionnelle” ou “# défauts.” Nous les plaçons sur un tableau blanc. Puis on esquisse les lignes de lien causaux entre les notes adhésives. Il y aura (ou devrait avoir) de nombreuses réécritures, effacements, et retracés durant la session de modélisation. Le résultat le plus signifiant est la compréhension ; par addition, certains participants voudront prendre une photo numérique du dessin sur le tableau blanc.

Voir les Dynamiques Système : Les Diagrammes de Causalité

Les diagrammes de causalité sont utilisés régulièrement dans les introductions à LeSS, pour aider à voir les dynamiques de ce qui se passe dans un développement à grande échelle. C’est utile de les comprendre pour cette seule raison. Et encore plus utile pour vous, nous vous recommandons de le faire ensemble avec les collègues devant le tableau blanc. Modéliser pour avoir une conversation. Quand ? Probablement pendant une Rétrospective LeSS Globale.

L’aspect practique de cette astuce est plus important qu’on pourrait l’apprécier de prime abord. Cela reste vague et donne peu d’impacts de suggérer “d’être un penseur de systèmes.” Mais si vous et quatre de vos collègues prennez l’habitude de vous tenir devant un grand tableau blanc, de dessiner des diagrammes de causalité ensemble, alors il y a une practice concrète et potentialement à fort impact qui connecte “être un penseur de systèmes” avec “faire de la pensée systémique.”

Les exemples suivants semblent stériles quand ils sont présentés dans un livre. Mais imaginez que vous soyez devant un tableau blanc avec d’autres personnes et que les diagrammes soient dessinés pendant une conversation animée. C’est la façon dont nous vous suggérons de ‘faire’ de la pensée systémique.

Notation et Exemples

Les diagrammes de causalité contiennent de nombreux éléments; le sous-ensemble classique et utile suivant est mise en oeuvre à travers un scénario.

• les variables
• les liens causaux
• les effets opposés
• les contraintes
• les buts
• les réactions ; réactions de réparation rapide
• les effets d’interaction
• les effets extrèmes
• les delais
• les boucles de rétroactions positifs

Le scenario simplifié suivant est pour une organisation spécifique. Ce n’est pas une généralisation.

Les variables—Les diagrammes de causalité incluent des variables (ou stocks) comme la vélocité (taux de délivrance) des fonctionnalités logicielles et le nombre de défauts . Les variables ont des quantité mesurables.

Les liens causaux–Un élément peut avoir un effet sur un autre, par exemple si la vélocité fonctionnelle augmente, alors le nombre de défauts augmente; c’est-à-dire, d’avantage de nouveau code, d’avantage de défauts.

Maintenant il est temps de rentrer dans la Loi de Weinberg-Brook et l’Erreur de Causalité . C’est facile de dessiner un diagramme; c’est autre chose de modéliser avec perspicacité. Par exemple, considérez les relations entre le nombre de développeurs et la vélocité fonctionnelle.

La nature de toute relation cause à effet n’est en fait pas évidente, bien qu’il soit commun pour les gens tirer des conclusions comme plus de développeurs signifie une meilleure vélocité. Ajouter des personnes tard dans le développement peut réduire la vélocité (une sous-partie de la “Loi de Brooks’” [Brooks95]). Ou bien, d’avantage de mauvais programmeurs peuvent réellement vous ralentir. Un argument peut être que enlever les développeurs terribles peut améliorer la vélocité.

Les effets opposés—Un effet de lien causal peut être une direction semblable ou opposée ; si A monte alors B monte, ou vice versa. Un effet opposé est montré avec un ‘O’ sur la ligne. Supposez que les défauts augmentant, entrave le système, réduisant la vélocité des nouvelles fonctionnalités car les gens passent plus de temps à réparer ou à résoudre les problèmes.

Les contraintes—Hormis de pouvoir trouver des personnes gratuites, il y a une contrainte sur le nombre of développeurs, basé sur la capacité financière.

Les contraintes ne sont pas des liens causaux. Lorsque la capacité financière grimpe, il n’est pas avéré que le nombre de développeurs grimpe.

Les buts et les réactions–Les personnes, les départements, et les systèmes ont des buts, comme une plus grande vélocité fonctionnelle . Les buts génèrent souvent de la pression pour les gens réagissent (ou agissent), avec l’intention d’atteindre le but. Mais comme il y a Erreur de Causalité et la Loi de Weinberg-Brooks pour contester, les gens devraient être prudent quant à assumer quelles actions vont aider. Maintenant un but et la pression de réaction est montré :

Non seulement un but avec récompense crée de la pression pour agir, mais il crée aussi de la pression pour apparaître en train d’agir et de réaliser, dû au disfonctionnement de la mesure généré par les récompenses. Et le disfonctionnement de la mesure peut être proportionnel á la valeur perçue de la récompense car les personnes sont motivées pour obtenir une récompense, non à améiorer le système [Austin96]. Remarquez comment les récompenses peuvent en fait dégrader la performance du système . Visuellement, les dynamiques système peuvent être…

Il est assez intéresant que toutes ces dynamiques aient été ajoutées par l’introduction de récompenses, et pourtant il y n’a aucune connection nécessaire entre la partie haute modèle et la partie basse.

Il n’y a aucune guarantie que la vélocité fonctionnelle ait été améiorée—ou même qu’on ait travaillé dessus.

Suupprimer le système de récompense est une solution aux causes de disfonctionnement. Une autre (et moindre) contremesure de surface est le principe de la pensée lean Aller Voir (aller voir physiquement sur les lieux de travail réel) et le comportement managérial :

Les réactions à solution rapide—Une solution difficile et lente vers le but d’une plus grande vélocité est de recruter de très bons développeurs, d’augmenter le coaching et la formation du personnel existant, et d’enlever les travailleurs terribles. L’alternative est appelée une solution rapide , une réaction qu’on espère pour atteindre le but rapidement et avec peu d’efforts. De temps en temps une solution rapide marche bien à la fois sur le court et le long terme, renforçant réelement le système. De temps en temps non…trivial, “plus rapide est plus lent.” Par exemple, certains peuvent croire qu’accroître le nombre de développeurs augmente la vélocité fonctionnelle. Et ils peuvent ainsi espérer que recruter d’avantages de développeurs va plus rapidement et plus facilement résoudre le problème de la vélocité. ‘QF’ (Quick Fix) indique la solution rapide :

Les effets d’interaction—Il y a la contraine de la disponibilité de trésorerie lorsqu’on recrute.Une solution difficile et lente est d’obtenir d’avantages de trésorerie. Une solution plus rapide consiste à recruter plus de développeurs peu chers. Dans ce cas, le niveau de disponibilité de trésorerie possède maintenant un effet d’interaction avec d’autres liens causaux. Une faible trésorerie a tendance à renforcer le taux de recrutement de développeurs moins chers quand il y a une pression à accroître les taux d’embauche.

On pourrait simplement tracer un lien causal (opposé) directement à partir de la disponibilité de trésorerie vers le taux d’embauche de développeurs très peu chers , mais cela dit principalement que moins de trésorerie mène vers d’avantage de recrutement de développeurs extrèmement bon marché. Ce n’est pas ce que nous voulons dire ; plutôt, nous voulons montrer l’effet d’interaction–cet effet A influence l’effet B. On le fait en montrant un lien causal entrant dans un autre lien causal. Par exemple, de disponibilité de trésorerie (cash supply) vers la ligne de solution rapide allant dans haut taux de développeurs très bon marché (hire rate of very cheap developers) :

Les effets extrêmes—Nous avons travaiilleé avec des développeurs vraiment pas chers du tout avec d’excellents compétences et des développeurs particulièment coûteux qui étaient terribles, mais en moyenne, vous avez ce pour quoi vous payez–quand vous recrutez à partir d’un bassin d’emploi très bon marché, le niveau moyen de compétences est plus faible. Dans le modèle, nous voulons montrer que l’impact de recruter de la main d’oeuvre bon marché sur le nombre de développeurs faiblement compétents a un effet significativement plus grand qu’en moyenne.

Pour montrer un effet extrême dans le modèle, utiliser une line épaisse :

Les retards—Un problème dans le recrutement en développement logiciel est l’illusuion de variance du programmeur moyen —la fausse croyance que la variance du programmeur (en termes de productivité, de qualité de code, etc.) est relativement faible. Cependant, les études de variance de programmeur suggèrent une moyenne de quatre fois plus vite dans le quartier du haut par rapport à celui du bas [Prechelt00]. Plutôt significatif. Aussi, le modèle COCOMO—basé sur des études en long et en large—montre que l’aptitude du personnel de développement est de loin le facteur le plus important pour la productivité [Boehm00]. Et, en moyenne, les programmeurs particulièrement médiocres créent du code de mauvaise qualité (mauvais design) et d’avantages de défauts, créant un autre frein sur le système.

Mais les impacts de ces effets ne sont pas are immédiatement évidents. Par exemple, cela prend un temps relativement long après avoir recruté un grand nombre de programmeurs médiocres avant qu’on commence à ressentir les impacts d’avoir de plus en plus de mauvais code/design. De même, la décroissance moyenne en vélocité fonctionnelle (dûe à l’impact puissant de la variabilité des programmeurs) ne sera pas visible immédiatement.

Pour montrer ces effets retardés dans le modèle, utiliser une double barre en travers de la ligne d’effet :

Le retard a une curieuse influence sur la puisssance éducative ou corrective dans un système. Si un impact ou une conséquence inattendue est fortement retardée, on n’en ressent pas les effets (posiitifs ou négatifs) et donc on ne voit pas clairement en quoi A influence B, ou plus subtilement comment A influence B qui influence A .

Pour cette raison, on n’apprend pas ou on ne corrige pas ses erreurs—en politique, des actions de management, des outils, et ainsi de suite. Egalement, une amélioration graduelle à travers la pratique de la pensée lean du kaizen peut prendre un long temps; de la patience et de la perspicacité sont nécessaires pour voir si et comment les choses s’améliorent.

Les boucles de rétroaction positives—Les boucles de rétroactions négatives ou positives⁵ et les délais sont ce par quoi il faut commencer pour trouver plus de subtilités dans un système—et dans la compréhension du système. Par exemple, comment devient-on un meilleur programmeur ? En partie, par le mentoring de très bons programmeurs et en voyant de nombreux exemples de très bon code. Mais un bureau avec beaucoup de développeurs sans compétences ne génère pas beaucoup d’exemples de trés bon code, ni même il n’attire ou ne retient la petite partie de bons programmeurs qui pourraient agir comme mentors. Ils préfèrent travailler ailleurs.

Maintenant le groupe de développement commence à entrer dans spirale descendante d’auto-réenforcement—un ensemble de boucles de rétroactions positives . Heureusement, la tendance descendante est constrainte par la disponibilité de trésorerie.

D’avantage de bons programmeurs—qui pourraient fabriquer du bon code et servir de mentor aux autres—s’en vont. Il y a donc de moins en moins de code de qualité code à regarder et à utiliser pour apprendre. Le pourcentage de mauvais programmeurs augmente encore plus et la vélocité fonctionnelle tombe plus bas. Le code devient moins propre, plus gênant, et criblé de duplications, de sorte que la capacité d’implémenter rapidement des fonctionnalités diminue. Comme la vélocité fonctionnelle tombe encore plus bas, il y a d’avantage de pression pour recruter vite d’avantage de programmeurs très très peu chers. Tout cela mène à de multiples boucles de renforcement positif dans le système, par exemple :

Astuce : Vous pouvez trouver des boucles de rétroactions positives en trouvant les cycles avec un nombre impairede relations à effet ‘Opposé’. Il y a plusieurs exemples dans le modèle ci-desssus.

Conclusion

Le scénario d’exemple n’est que cela—un exemple. Un diagramme de causalité permet de visualiser des dynamiques riches dans un système sur le lieu de travail. Ceux-ci sont mieux créés par un groupe sur un tableau blanc.

Voir les Modèles Mentaux

Les diagrammes de causalité précédents reflètent les modèles mentaux de causalité des personnes, qui peuvent être faux. Il est intéresant de noter que les modèles de causalité des personnes sont influencés par l’actualité (délais) et la qualité du retour dans le système.

L’implication des “modèles mentaux” est d’améliorer notre compétence meta-cognitive à voir et à questionner nos propres hypothèses et nos chaînes de raisonnement. Faisons-nous des sauts de logique erronés ? Cela implique aussi, lorsqu’on travaille avec d’autres, de discuster (investiguant plutôt qu’invectivant) les modèles mentaux de nos collègues.

Voir ces modèles mentaux est la première étape; les changer est la part encore plus difficile de l’étape deux. Cet art est au delà du périmètre de cette introduction, quoiqu’une adoption réussie de LeSS doit impliquer des changements d’état d’esprit et de points de vue parmi de nombreux groupes.

Une astuce pour mieux voir les modèles mentaux (croyances, chaînes d’inférence, …) en jeu dans les dynamiques systémiques consiste à poser la question suivante pendant un atelier de modélisation et ensuite de dessiner les réponses. “Parlons des hypothèses derrière ce modèle. Que croyons-nous ou supposons en termes de faits et d’effets qui nous ont amenés jusqu’ici ?”

Les réponses sont dessinées sur un tableau blanc, par exemple:

o

Exemple : La Dynamique “Plus vite est moins vite”

Avec le vocabulaire des solutions rapides (QF), des délais, des boucles de rétroaction positive, et des modèles mentaux, c’est fascinant de voir qu’il peut y avoir une amélioration apparente à court terme sur une variable comme le résultat d’une solution rapide, mais une dégradation retardée de cette même variable—la dynamique “plus vite est moins vite”. C’est une dynamique récurrente sur les lieux de travail et une cause de fragilité. C’en est une pire illustration.

L’histoire de Microsoft Word et de la boite à outils secrète du développeur : Un exemple classique d’‘amélioration à court terme mais de dynamique dégénérative à long terme est l’histoire de la première version de Microsoft Word pour Windows [Spolsky04]. Il a été livré des années après la date souhaitée. Pourquoi ? Parce que les managers essayaient de suivre le planning initial et poussaient les développeurs à le respecter .

L’histoire illustre pourquoi le voeu pieux est identifié comme une des pertes dans la pensée lean. Dans ce cas, le voeu pieux est d’insister sur un (apparent) suivi du planning, ce qui sous-entend la méconception ou le voeu pieux que les estimations de développement ne sont pas des estimations mais sont des engagements—un mythe classique qui propulse la dégradation d’un système.

Le modèle suivant illustre un résumé des dynamiques de ce qui se produit lorsque les managers incitent trop les gens à se conformer évidemment au planning d’origine, et pourquoi cette réaction de solution rapide consistant à ralentir les progrès a semblé rendre les choses plus vite sur le court terme mais en réalité les a encore plus ralenties sur le long terme. Regardez la dynamique de la pression du planning et de la boite à outils secrète. Nous avons volontairement omis certaines dynamiques plus profondes qui sont développées et affichées dans Voir les dynamiques profondes de la pression du planning et de la boîte à outils secrète.

Comme solution rapide, les managers de Microsoft ont exhorté, corrompu (avec des récompenses potentiellles), et menacé les développeurs Word de rester sur le planning d’origine. En conséquence, les développeurs ont dégainé de manière prévisible leur boite aàoutils secrète de développeur —les nombreuses practiques relatives au piratage de code sale (pas de tests, pas de revues, ignorer les défauts connus, programmation par copier-coller, faible design, …) pour liver en apparence une fonctionnalité plus vite. Vous voyez, les développeurs aussi ont leurs réactions solution rapides pour leurs problèmes.

La tactique semblait avoir fonctionné comme par magie. Alors que les managers mettaient plus de pression sur les développeurs, les ‘fonctionnalités’ furent livrées plus rapidement lorsque les gens utilisaient la boite à outils secrète, ce qui renforçait la croyance que ça aidait de mettre de la pression sur les développeurs. Mais cette accéleration apparente a en fait eu un effet négatif á retard pour rendre les choses plus lentes, ce qui est exploré ensuite. Comme le management n’a pas vu rapidement l’effet à retard de la boite à outils secrète, et parce qu’ils croyaient que les managers ne doivent pas regarder fréquemment en détail dans le code source ou être eux-mêmes des programmeurs expérimentés, ils n’ont pas appris de ces dynamiques.

Une exploration plus fine des dynamiques système montre pourquoi les choses sont allées plus lentement sur le long terme et pourquoi la première version de Word for Windows était en retard de plusieurs années, ce qui est illustré dans ce modèle…

Naturally, beaucoup de code sale ralentissait finalement les choses. Plus subtilement, les développeurs ignoraient la liste continuellement croissante des défauts ouverts pour—à la place—générer de nouvelles fonctionnalités. Cela amenait à un long delais entre la création d’un défaut et sa correction. Il se trouve que cela a significativement accru la variabilité et le temps pour corriger un défaut à cause de l’effet négatif de composition d’un bug à la vie longue (par exemple, dû aux contournements and au couplage) et parce que les développeurs ont oublié depuis longtemps le contexte détaillé du code lié au défaut et doivent donc redécouvrir lentement ce contexte - avec de plus en plus de code confus qui l’entoure.

Le lecteur astucieux peut également remarquer les différentes boucles de rétroaction positive qui renforcent le cycle de dégradation; c’est une des raisons pour lesquelles le produit était arrivé des années plus tard que prévu.

La solution? Les principes de la pensée lean de Stop et Corrige et Aller Voir. Tout d’abord, plutôt que d’essayer d’aller plus vite quand il y a des problèmes, les enseignants-manager encouragent les gens à aller moins vite et les aide à apprendre à voir les dynamiques système et les causes racines, et à les corriger—pour améliorer le système de développement. En allant moins vite, Toyota—les maîtres de la pensée lean—est devenu une des compagnies les plus rapide. Ensuite , que les managers aillent voir sur le lieu de travail réel pour apprendre ce qui se passe. La “place réelle” en développement logiciel est le code,
ce qui suggère que les managers de premier niveau sont des maîtres programmeurs qui évaluent fréquemment le code.

Les gens chez Microsoft n’ont réfléchi à la situation qu’après la sortie. Quand ils ont finalement fait une rétrospective, cela a mené à une politique de zéro-défaut, ce qui signifie que la première priorité était de corriger des bogues connus dans le code en cours de développement, —afin de réduire la liste des défauts ouverts avant de rédiger un nouveau code de nouvelle fonctionnalité.

Voir (et Entendre) L’Optimisation Locale

“Tout le monde fait de son mieux, mais le débit global des systèmes se dégrade. Comment cela peut-il être ?” C’est le paradoxe de l’optimisation locale —quand une personne ou un décideur optimise à son simple niveau ou pour son intérêt personnel. Les parties prenant la décision croient souvent qu’elles prennent la meilleure décision , mais parce que ‘meilleure’ est une optimisation locale, en fait elle sous-optimise le débit système global. C’est le résultat d’une “mentalité de silo,” de malentendu, de peur, d’information limitée, de feedback différé, d’ignorance, de carièrisme, d’avarice, et d’autres troubles de l’apprentissage organisationnel classiques.

Un petit groupe produit de 30 personnes n’a pas le temps ni l’argent pour se livrer à ces nombreuses absurdités ou ces gaspis. Mais les grandes compagnies, avec leur grands groupes produit, leur groupes process et outils centralisés, un “project management office” centralisé, et ainsi de suite, semblent avoir augmenté l’optimisation locale et les gaspis dans une forme d’art. Les bureaucraties gouvernementales en sont l’exemple par excellence, bien sûr. Comme tel, lorsque vous servez de guide pour une adoption agile à grande échelle, voir (ou entendre) et traiter avec l’optimisation locale est singulièrement vital.

Par exemple, les départements juridiques et de sécurité de l’entreprise mettent en place une politique qui semble terriblement importante de leur point de vue. Dans le but de prévenir les pertes de propriété intellectuelle (IP), le département décrete que “personne ne doit mettre aucune information sur les murs.” Ou bien, en réponse à la pression de réduire les coûts, la gestion des installations dit, “Il est important de s’assurer que nos murs ne soient pas sales ou endommagés.” Et ainsi ils arrêtent une pratique de la pensée lean, le management visuel (qui est fait habituellement sur les murs), et ils inhibent une pratique d’innovation bien connue, le travail de groupe au tableau blanc. Les avocats peuvent réussir à réduire la perte de propriété intellectuelle (en fait, ce qui est discutable), et les gens des installations réussiront à garder les murs propres—au prix d’inhiber le group de développement produit d’innover et de collaborer. Enfin, la compagnie est en retard avec de moins en moins de propriété intellectuelle même en valeur à protéger car les outils d’innovation et de livraison rapides ont été interdits, mais les avocats ont réussi à remplir leur mandat donné par l’équipe de direction pour “assurer notre protection de la propriété intellectuelle.” Et la police des meubles a des murs clairs. Ils ont fait de leur mieux.

La suite reproduit une réelle citation d’e-mail de la POLICE DES MEUBLES dans une organisation qui a refusé management visuel sur les murs. Pouvez-vous identifier les optimisations locales et les modèles mentaux qui y conduisent ?

• La partition cubique de travail individuel peut être personnalisée. Mais les choses évidentes plus élevées que la partition ou le fait de nuire à l’harmonie de l’environnement de bureau sont restreintes.*

Nous voyons également l’optimisation locale dans des groupes centralisés qui font des choix d’outils logiciels pour d’autres. La mentalité classique consiste à choisir un outil qui permet de réduire le coût supposé (de manière curieuse, ces groupes recommandent rarement des outils open source gratuits) ou mieux en faisant quelque chose de compliqué ou mieux pour le travail d’un rôle de travail spécialisé (même si tout le monde doit utiliser cet outil), plutôt que de maximiser l’objectif global d’un débit plus rapide du système pour les clients.

Dans l’adoption à grande échelle de Scrum ou des principes agiles, la plupart des problèmes “Oui, mais …” qui sont soulevés sont des exemples d’optimization locale, tel que, “Oui, mais… qu’en est-il des rapports de management *?” ou plus généralement, “Oui, mais…qu’en est-il de *?” Ensuite, les politiques et les pratiques sont retournées, pour servir l'objectif de reporting ou un autre but secondaire plutôt que l'objectif principal d'optimiser le débit rapide. Parfois, on voit *l'optimisation locale pour le cas extrême ou rare*. Par exemple, une personne responsable de faire un choix d'outil centralisé pour une entreprise présente un scenario pour un cas d'utilisation complexe ou rare, et ensuite choisi l'outil qui s'y adapte, en sous-optimisant pour 5 pourcent des cas au lieu de d'optimiser pour la facilité et la vitesse de 95 pourcent des cas.

D’autres optimisations locales sont dûes à l’ignorance des nouvelles façons de travailler. Ceci est particulièrement fréquent dans les groupes produit à grande échelle. Par exemple, nous avons aidé un grand groupe de produits réseau en Europe à adopter Scrum et les pratiques d’ intégration continue (CI) combinée avec un système CI qui intègre continuellement, construit, et teste automatiquement le produit. Après quelques temps, un manager tradionnel externe a inspecté ce qui se passait, et a recommandé que les practiques d’intégration devraient être changées—parce qu’il n’y avait aucun plan d’intégration écrit pour qu’un gestionnaire d’intégration humain puisse manuellement intégrer tout le logiciel, et bien sûr, il n’y avait pas de gestionnaire d’intégration. Ils voulaient ‘optimiser’ le travail d’un gestionnaire d’intégration qui n’était plus nécessaire. Ils ne pouvaient pas voir que leur modèle de travail à l’ancienne avait été éliminé avec CI. Cette histoire se répète dans tous les départements d’un grand produit établi : l’optimisation locale autour des modes de travail existants, tels que le test manuel, un département d’architecture séparé, des équipes de composants, etc. Un coach qui travaille à introduire Scrum à grande échelle au niveau de l’entreprise a une montagne de pensée d’optimisation locale similaire à traiter.

Dans la pensée lean et les méthodes agile, l’accent est mis sur les objectifs de systèmes globaux: Delivrer de la valeur rapidement avec de la qualité et de la morale—optimisation globale . Essayez d’examiner les décisions à la lumière de cet objectif. Pour développer une culture “optimiser l’ensemble”, remettez en question toutes les décisions et toutes les politiques avec la question :

Est-ce que cette décision ou cette politique se concentre sur la valeur ajoutée du client externe, ou ee concentre-t-il sur les intérêts d’un département, d’une personne, d’une politique / pratique interne ou d’un cas rare ?

En LeSS, le Product Owner est responsable de choisir les objectifs de haute valeur qui peuvent mener à un produit potentiellment livrable (à la fin d’un Sprint) et qui maximise les impacts désirés et qui ravit 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 une optimisation globale plutôt que locale.

Conclusion

En plus de devenir un penseur de systèmes vous-même, encouragez les autres à en apprendre davantage sur ce sujet. Nous vous suggérons d’essayer de vous réunir devant un tableau blanc avec des collègues pour esquisser un diagramme de la causalité, de sorte qu’être des penseurs de systèmes et faire de la pensée de systèmes soient connectés sur le lieu de travail.

Lectures Recommandées

• Out of the Crisis de W. Edwards Deming est un travail remarquable par le penseur de systèmes et l’expert qualité le plus connu. Il s’ouvre avec le but modeste, “Le but de ce livre est la transformation du style de management américain… Il requiert une toute nouvelle structure, depuis la fondation vers le haut.” Deming préconise également le Système de Connaissance Approfondie dans lequel les managers (1) apprécient qu’il existe un système, (2) comprennent la cause commune et la variation de cause spéciale (la théorie des files d’attente est liée à la variation), (3) comprennent les limitations du savoir et les erreurs de raisonnement, et (4) prennent connaissance de psychologie credible et des résultats de recherches sociales de sorte que les politiques relatives au comportement ou à la motivation ne sont pas basées sur le “bon sens.” Le coeur du livre est centré autour de ses fameux 14 Points de Management , incluant (par exemple), “Éliminer le management par objectif. Éliminer le management par les nombres, les objectifs chiffrés. Substituer le leadership .”
  
• Industrial Dynamics de Jay Forrester est le texte classique text sur les dynamiques système —bien écrit et perspicace. Bien qu’écrit au début des années 1960, il est aussi pertinent aujourd’hui que lors de sa publication. Cela va au-delà de la modélisation des causes-effets pour modéliser également le flux et les inventaires de l’information, de l’argent et du matériel dans les systèmes. Le livre comprend une modélisation mathématique formelle, mais ce n’est pas obligatoire pour apprécier les dynamiques système.
• Quality Software Management: Systems Thinking et An Introduction to General Systems Thinking de Weinberg’s valent la peine. Écrits du point de vue d’un consultant expérimenté dans le développement de systèmes.
  
• La Cinquième Discipline de Senge est un classique qui préconise le besoin de leadership pour appliquer la pensée systémique (c’est la cinquième discipline) et d’autres disciplines clés pour une entreprise formidable et durable. Les autres comprennent les leaders avec (1) la maîtrise personnelle et (2) la réflexion sur leurs croyances et leurs raisonnements défectueux, la (3) définition et la communication d’une vision partagée et (4) la capacité des équipes à apprendre. Nous vous recommandons d’ignorer —au moins pendant les premières années de pratique— la notion d’‘archétypes’ présentée dans le livre. Il s’agissait d’une aide à l’apprentissage mais on a observé que cela distrayait et intimidait les gens à apprendre et à appliquer la modélisation de la dynamique des systèmes de base.
  
• The Fifth Discipline Fieldbook est une ressource en profondeur, écrit du point de vue de plusieurs practicants et consultants.
  
• Les écrits d’apprentissage organisationnel de Argyris, Putnam, McLain, et Schön. Les concepts importants incluent l’apprentissage en double boucle et le dialogue de haut plaidoyer / haute recherche. Les œuvres classiques comprennent Action Science et Organizational Learning.
  
• Les publications et les ressources disponibles sur Society for Organizational Learning.

---

Notes:

1. Senge a écrit La Cinquième Discipline, sur la pensée systèmique et les organisations apprenantes, nommé «l’un des livres de management fondamental des 75 dernières années» par la Harvard Business Review. Voir ** [Senge94].




2. Une autre raison: Il est possible d’avoir plus de contrôle possible qu’en réalité. La science de la complexité suggère des limites fondamentales pour prédire et contrôler les systèmes sociaux semi-chaotiques [Stacey07]. Il s’agit d’une assez grande boîte de vers qui restera ouverte dans ce livre.




3. La macroéconomie, la psychologie, la sociologie et la biologie sont des exceptions, parmi d’autres.




4. ‘Basic’ ne signifie pas trivial ou facile à résoudre. Par exemple, ‘motivation’ et ‘qualité’ sont des problèmes simples mais pas faciles.




5. Les boucles de rétroaction est parfois utilisé dans ce livre dans le sens colloque de la rétroaction, plutôt que le sens des dynamiques système.