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

De Wiki Agile
Ligne 313 : Ligne 313 :


== Voir (et entendre) l’optimisation locale ==
== Voir (et entendre) l’optimisation locale ==
"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 qu'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''.


“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''.
Une petite équipe produit de 30 personnes n’a ni le 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.


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.
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 moyens, soumis de son côté à une pression de politique de réductions des 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 moyens 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 pour "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''.


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''.
Ce qui suit est extrait d’un vrai mail 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 ?


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?
Les [https://fr.wikipedia.org/wiki/Bureau_%C3%A0_cloisons bureaux à cloisons] peuvent être personnalisés. Mais tout ce qui est visible au-dessus de la cloison ou qui perturbe l’harmonie de l’environnement de bureau est interdite.


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 ?
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 open source 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.


<blockquote>''Individual work cubic partition can be personalized. But things obvious higher than the partition or harming the office environment’s harmony are restricted.''
</blockquote>
<blockquote>_Les [https://fr.wikipedia.org/wiki/Bureau_%C3%A0_cloisons 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.
</blockquote>
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.
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.


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


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.
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 globale", remettez donc en cause toutes les décisions et les règles avec la question suivante :


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:
'''Est-ce que cette décision ou cette règle se focalise sur le fait de 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 ?


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 :


<blockquote>'''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?'''
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 enchantant 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.
</blockquote>
<blockquote>** 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 ?**
</blockquote>
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 ==