Less - Plus avec LeSS : Différence entre versions

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher
Ligne 2 : Ligne 2 :
 
[[Category: Agilité à grande échelle]]
 
[[Category: Agilité à grande échelle]]
 
Auteur : The LeSS Company B.V.<br/>
 
Auteur : The LeSS Company B.V.<br/>
Source : [https://less.works/less/principles/more-with-less.html More with LeSS]
+
Source : [https://less.works/less/principles/more-with-less.html More with LeSS]<br/>
 
----
 
----
 
Traducteur : Nicolas Mereaux<br/>
 
Traducteur : Nicolas Mereaux<br/>
 
Relecteur : Fabrice Aimetti<br/>
 
Relecteur : Fabrice Aimetti<br/>
Date : 19/10/2018
+
Date : 19/10/2018<br/>
 
----
 
----
Traduction :
+
Traduction :<br/>
 
+
<br/>
[[LeSS - Portail Principes]]
+
[[LeSS - Portail Principes]]<br/>
 
+
<br/>
The ''More with LeSS'' principle is at the heart of LeSS. It’s the realization that the disadvantages of the complex organizational solutions that are used for complex product development are often worse than the problem they try to solve. Complex product development doesn’t require complex solutions. It requires a deep understanding of the essence of the problems, which can then be solved with simpler solutions.
+
Le principe ''Plus avec LeSS'' est au cœur de LeSS. Il s'agit de la prise de conscience que les désavantages des solutions organisationnelles complexes utilisées pour le développement de produits complexes sont souvent pires que le problème qu'elles essaient de résoudre. Le développement de produits complexes ne nécessite pas des solutions complexes. Il demande une compréhension profonde de l'essence du problème, qui peut être alors résolu avec des solutions plus simples.<br/>
 
+
<br/>
Le principe ''Plus avec LeSS'' est au cœur de LeSS. Il s'agit de la prise de conscience que les désavantages des solutions organisationnelles complexes utilisées pour le développement de produits complexes sont souvent pires que le problème qu'elles essaient de résoudre. Le développement de produits complexes ne nécessite pas des solutions complexes. Il demande une compréhension profonde de l'essence du problème, qui peut être alors résolu avec des solutions plus simples.
+
LeSS peut être perçu comme un cadre de travail de développement de produit à ''grande échelle'', mais il peut aussi être vu comme un cadre de travail pour ''décomplexifier'' les organisations. LeSS tente de supprimer la complexité organisationnelle en résolvant les problèmes dans le développement de produits d'une manière différente et plus simple. Notons que plus simple, ne veut pas dire plus facile, notamment à court terme. Même si LeSS est simple, il est exceptionnellement difficile à mettre en place dans les organisations.<br/>  
 
+
<br/>
LeSS can be viewed as a ''scaling'' framework for product development, but can also be viewed as a ''descaling'' framework for organizations. It attempts to remove organizational complexity by solving problems in product development in a different and simpler way. Note that simpler doesn’t mean easier, especially in the short run. Even though LeSS is simple, it is exceptionally hard to adopt well in organizations.
+
LeSS tente de définir le strict nécessaire suffisant pour un développement à grande échelle. LeSS évite d'ajouter des rôles, artefacts, ou processus supplémentaires, parce qu'il sait ce que représente l'inconvénient de ces ajouts.<br/>
 
+
<br/>
LeSS peut être perçu comme un cadre de travail de développement de produit à ''grande échelle'', mais il peut être vue comme un cadre de travail pour ''détartrer|décomplexifier'' les organisations. LeSS tente de supprimer la complexité organisationnelle en résolvant les problèmes dans le développement produit d'une manière différente et plus simple. Notons que plus simple, ne veut pas dire plus facile, notamment à court terme. Même si LeSS est simple, il est exceptionnellement difficile à être bien adopté dans les organisations.   
+
Un rôle est un ensemble de responsabilités ou de tâches assignées à un individu. Le plus souvent, il ne s'agit pas de nouvelles responsabilités ou de nouvelles tâches. Donc définir un nouveau rôle signifie que ces responsabilités seront enlevées à quelqu'un d'autre. Dans le développement de produits, cela signifie qu'elles sont pour la plupart du temps retirées aux équipes.<br/>  
 
+
<br/>
LeSS attempts to define the barely sufficient needed for large-scale development. It avoids adding additional roles, artifacts, or processes, as it realizes the drawbacks of these additions.
+
Plus il y a de rôles, moins les équipes sont responsables.<br/>
 
+
<br/>
LeSS tente de définir le strict nécessaire suffisant pour un développement à grande échelle. LeSS évite d'ajouter des rôles, artefacts, ou processus supplémentaires, en raison de la prise de conscience que représentent ces inconvénients de ces ajouts.
+
Un ''processus'' est une description de la manière dont le travail doit se passer. C'est une manière de partager la connaissance; Mais ! … cela conduit aussi les gens à arrêter de penser. L'interprétation de la mise en place d'un processus est qu'il n'y a plus besoin de penser à comment faire le travail, car cette réflexion a été faite par les personnes qui ont défini le processus. C'est ''suivre'' plutôt que changer (et apprendre), et c'est ''louer'' plutôt que s'approprier la connaissance. Donc définir plusieurs processus empêche les équipes de s'approprier la manière de faire le travail. Et des équipes sans sentiment d'appropriation ne pourront pas s'améliorer.<br/>
 
+
<br/>
A role is a set of responsibilities or tasks assigned to an individual. Most often, these are not newly-invented responsibilities or tasks. Thus defining a new role means these responsibilities are removed from somewhere else. In product development, most commonly they are removed from the teams.
+
Plus il y a de processus mis en place moins il y a d'appropriation dans les équipes et une absence d'amélioration continue.<br/>
 
+
<br/>
Un rôle est un ensemble de responsabilités ou de tâches assignées à un individu. Le plus souvent, il ne s'agit pas de nouvelles responsabilités ou de nouvelles tâches. Donc définir un nouveau rôle signifie que ces responsabilités seront enlevées à quelqu'un d'autre. Dans le développement produit, cela signifie qu'elles sont pour la plupart retirées aux équipes.   
+
Un ''artefact'' est une information ou une connaissance qui est formalisée et enregistrée. Dans un développement traditionnel de produit, tout un ensemble d'artefacts sont produits en tant que méthode de communication. La plupart de ces artefacts éloignent les équipes du client ou de l'utilisateur réel, les équipes croyant ou il leur a été dit qu'elles peuvent se référer à l'artefact à la place. Cela pourrait sembler convenable, mais en pratique les artefacts dépouillent les équipes de la compréhension client et de l'objectif du développement produit, et cela empêche l'empathie.<br/>
 
+
<br/>
More roles lead to less responsible teams.
+
Plus il y a d'artefacts moins les équipes sont orientées client.<br/>
 
+
<br/>
Davantage de rôles conduit à des équipes moins responsables.
+
Garder à l'esprit ''Plus avec LeSS'' nous permet de penser différemment au sujet du développement produit.<br/>
 
+
<br/>
A ''process'' is a description of how work needs to happen. It is a way of sharing knowledge. But! … it also leads people to stop thinking. The interpretation of installing a process is that there is no further need to think about how to do the work, as that thinking has been done by the people who defined the process. It’s _following_ over changing (and learning), and it’s _renting_ over owning knowledge. . So defining many processes takes away the ownership of how to do the work from the teams. And teams without ownership will not improve.
+
Au lieu de demander "Comment pouvons-nous faire X d'une manière agile ?" où X est la pratique ou la structure organisationnelle actuelle, nous posons d'abord la question "Pourquoi faisons-nous X d'abord ?" pour voir si nous pouvons trouver une meilleure solution au problème d'origine. Par exemple, "Comment faisons-nous de la gestion de programme d'une manière agile ?" est une question récurrente du passage à grande échelle, alors que, en gardant le principe _Plus avec LeSS_ à l'esprit, nous nous demandons "Pourquoi devons-nous faire de la gestion de programme d'abord ?". Ce qui nous conduit à prendre conscience que les programmes (les grands projets) sont une manière d'organiser le travail, qui peut être organisé différemment. Par exemple, avec une orientation davantage produit, en travaillant vers un objectif de livraison continue, et avec une planification adaptative, tout cela nous mène à être capable de gérer le développement produit sans recourir aux programmes.<br/>
 
+
<br/>
Un ''processus'' est une description de la manière dont le travail doit se passer. C'est une manière de partager la connaissance; Mais ! … cela conduit aussi les gens à arrêter de penser. L'interprétation de la mise en place d'un processus est qu'il n'y a plus besoin de penser de comment faire le travail, car cette réflexion a été faite par les personnes qui ont défini le processus. C'est ''suivre'' plutôt que changer (et apprendre), et c'est ''louer'' plutôt que s'approprier la connaissance. Donc définir plusieurs processus enlève cette appropriation aux équipes quant à la manière de faire le travail. Et des équipes sans sentiment d'appropriation ne pourront pas s'améliorer.
+
La même manière de penser s'applique à d'autres complexités organisationnelles, simplifiant peu à peu les organisations.<br/>
 
+
<br/>
More installed processes leads to less ownership in the teams and no continuous improvement.
+
Références :<br/>
 
 
Plus il y a de processus mis en place moins il y a d'appropriation dans les équipes et une absence d'amélioration continue.
 
 
 
An ''artifact'' is information or knowledge that is formalized and recorded. In traditional product development, a lot of artifacts are produced as a method for communication. Most of these are keeping the teams away from the actual customer or user, as they believe or have been told that they can refer to the artifact instead. This might seem good, but in practice the artifacts remove the customer understanding and purpose from product development for the teams, and prevent empathy.
 
 
 
Un ''artefact'' est une information ou une connaissance qui est formalisée et enregistrée. Dans un développement traditionnel de produit, tout un ensemble d'artefacts sont produits en tant que méthode de communication. La plupart de ces artefacts éloignent les équipes du client ou de l'utilisateur réel, les équipes croyant ou il leur a été dit qu'elles peuvent se référer à l'artefact à la place. Cela pourrait sembler bien, mais en pratique les artefacts dépouillent les équipes de la compréhension client et de l'objectif du développement produit, et empêche l'empathie.
 
 
 
More artifacts leads to less customer-centric teams.
 
 
 
Davantage d'artefacts mènent à des équipes moins orientée client.
 
 
 
Keeping ''More with LeSS'' in mind allows us to think differently about product development.
 
Instead of asking “How can we do X in an agile way?” where X is a current practice or organizational structure, we first first ask the question “Why did we do X anyways?” to see if we can find a better solution to the original problem. For example, “How do you do program management in an agile way?” is a traditional scaling question, whereas, when keeping the _More with LeSS_ principle in mind, we ask, “Why do we have program management in the first place?” That leads us to the realization that programs (large projects) are a way of organizing work, which can be organized differently. For example, with more of a product focus, working towards continuous delivery, and with adaptive planning, that all leads to being able to manage product development without programs.
 
 
 
Garder à l'esprit ''Plus avec LeSS'' nous permet de penser différemment au sujet du développement produit.
 
A la place de demander "Comment pouvons-nous faire X d'une manière agile ?" où X est la pratique ou la structure organisationnelle actuelle, nous posons d'abord la question "Pourquoi faisons-nous X d'abord ?" pour voir si nous pouvons trouver une meilleure solution au problème d'origine. Par exemple, "Comment faisons-nous de la gestion de programme d'une manière agile ?" est une question récurrente de passage à grande échelle, alors que, en gardant le principe _Plus avec LeSS_ à l'esprit, nous nous demandons "Pourquoi devons-nous faire de la gestion de programme d'abord ?". Ce qui nous conduit à la prise de conscience que les programmes (les grands projets) sont une manière d'organiser le travail, qui peut être organisé différemment. Par exemple, avec une orientation davantage produit, en travaillant vers un objectif de livraison continue, et avec une planification adaptative, tout cela nous mène à être capable de gérer le développement produit sans programmes.
 
 
 
The same way of thinking applies to other organizational complexities, gradually making organizations simpler.
 
 
 
La même manière de penser s'applique à d'autres complexités organisationnelles, simplifiant peu à peu les organisations.
 
 
 
Références :
 
 
 
 
* [https://www.ted.com/talks/yves_morieux_how_too_many_rules_at_work_keep_you_from_getting_things_done Video: How too many rules at work keep you from getting things done - Yves Morieux]
 
* [https://www.ted.com/talks/yves_morieux_how_too_many_rules_at_work_keep_you_from_getting_things_done Video: How too many rules at work keep you from getting things done - Yves Morieux]
 
* [https://less.works/blog/2015/05/08/less-scaling-descaling-organizations-with-less.html Descaling Organizations with LeSS - Viktor Grgic]
 
* [https://less.works/blog/2015/05/08/less-scaling-descaling-organizations-with-less.html Descaling Organizations with LeSS - Viktor Grgic]

Version du 19 octobre 2018 à 21:02

Auteur : The LeSS Company B.V.
Source : More with LeSS


Traducteur : Nicolas Mereaux
Relecteur : Fabrice Aimetti
Date : 19/10/2018


Traduction :

LeSS - Portail Principes

Le principe Plus avec LeSS est au cœur de LeSS. Il s'agit de la prise de conscience que les désavantages des solutions organisationnelles complexes utilisées pour le développement de produits complexes sont souvent pires que le problème qu'elles essaient de résoudre. Le développement de produits complexes ne nécessite pas des solutions complexes. Il demande une compréhension profonde de l'essence du problème, qui peut être alors résolu avec des solutions plus simples.

LeSS peut être perçu comme un cadre de travail de développement de produit à grande échelle, mais il peut aussi être vu comme un cadre de travail pour décomplexifier les organisations. LeSS tente de supprimer la complexité organisationnelle en résolvant les problèmes dans le développement de produits d'une manière différente et plus simple. Notons que plus simple, ne veut pas dire plus facile, notamment à court terme. Même si LeSS est simple, il est exceptionnellement difficile à mettre en place dans les organisations.

LeSS tente de définir le strict nécessaire suffisant pour un développement à grande échelle. LeSS évite d'ajouter des rôles, artefacts, ou processus supplémentaires, parce qu'il sait ce que représente l'inconvénient de ces ajouts.

Un rôle est un ensemble de responsabilités ou de tâches assignées à un individu. Le plus souvent, il ne s'agit pas de nouvelles responsabilités ou de nouvelles tâches. Donc définir un nouveau rôle signifie que ces responsabilités seront enlevées à quelqu'un d'autre. Dans le développement de produits, cela signifie qu'elles sont pour la plupart du temps retirées aux équipes.

Plus il y a de rôles, moins les équipes sont responsables.

Un processus est une description de la manière dont le travail doit se passer. C'est une manière de partager la connaissance; Mais ! … cela conduit aussi les gens à arrêter de penser. L'interprétation de la mise en place d'un processus est qu'il n'y a plus besoin de penser à comment faire le travail, car cette réflexion a été faite par les personnes qui ont défini le processus. C'est suivre plutôt que changer (et apprendre), et c'est louer plutôt que s'approprier la connaissance. Donc définir plusieurs processus empêche les équipes de s'approprier la manière de faire le travail. Et des équipes sans sentiment d'appropriation ne pourront pas s'améliorer.

Plus il y a de processus mis en place moins il y a d'appropriation dans les équipes et une absence d'amélioration continue.

Un artefact est une information ou une connaissance qui est formalisée et enregistrée. Dans un développement traditionnel de produit, tout un ensemble d'artefacts sont produits en tant que méthode de communication. La plupart de ces artefacts éloignent les équipes du client ou de l'utilisateur réel, les équipes croyant ou il leur a été dit qu'elles peuvent se référer à l'artefact à la place. Cela pourrait sembler convenable, mais en pratique les artefacts dépouillent les équipes de la compréhension client et de l'objectif du développement produit, et cela empêche l'empathie.

Plus il y a d'artefacts moins les équipes sont orientées client.

Garder à l'esprit Plus avec LeSS nous permet de penser différemment au sujet du développement produit.

Au lieu de demander "Comment pouvons-nous faire X d'une manière agile ?" où X est la pratique ou la structure organisationnelle actuelle, nous posons d'abord la question "Pourquoi faisons-nous X d'abord ?" pour voir si nous pouvons trouver une meilleure solution au problème d'origine. Par exemple, "Comment faisons-nous de la gestion de programme d'une manière agile ?" est une question récurrente du passage à grande échelle, alors que, en gardant le principe _Plus avec LeSS_ à l'esprit, nous nous demandons "Pourquoi devons-nous faire de la gestion de programme d'abord ?". Ce qui nous conduit à prendre conscience que les programmes (les grands projets) sont une manière d'organiser le travail, qui peut être organisé différemment. Par exemple, avec une orientation davantage produit, en travaillant vers un objectif de livraison continue, et avec une planification adaptative, tout cela nous mène à être capable de gérer le développement produit sans recourir aux programmes.

La même manière de penser s'applique à d'autres complexités organisationnelles, simplifiant peu à peu les organisations.

Références :