Fans of LeSS - Nous nous opposons à la corruption généralisée d'Agile et de Scrum : Différence entre versions

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher
 
(24 révisions intermédiaires par le même utilisateur non affichées)
Ligne 2 : Ligne 2 :
 
[[Category: Agilité à grande échelle]]
 
[[Category: Agilité à grande échelle]]
 
[[Catégorie:Portail LeSS]]
 
[[Catégorie:Portail LeSS]]
 +
[[Catégorie:Fans of LeSS]]
 +
[[Catégorie:Michael James]]
 +
[[Catégorie:Alistair Cockburn]]
 
[[Category: Portail Coach'Agile]]
 
[[Category: Portail Coach'Agile]]
Auteur : Fans of Less<br />
+
Auteur : &copy; 2019 Fans of LeSS<br />
 
Source : [https://fansofless.com/ fansofless.com]<br />
 
Source : [https://fansofless.com/ fansofless.com]<br />
 
Date : 03/08/2019<br />
 
Date : 03/08/2019<br />
Ligne 12 : Ligne 15 :
 
Traduction :<br />
 
Traduction :<br />
 
<br />
 
<br />
[[Fichier:Fans-of-LeSS-logo-white-background-596x337.png|left|100px]]Nous appelons B.S. (''bullshit'') ce qui est généralement vendu comme de l'Agile et du Scrum. Nous aimons les [https://agilemanifesto.org/iso/fr/manifesto.html quatre valeurs (fr)] et les [douze principes https://agilemanifesto.org/iso/fr/principles.html (fr)] du Manifeste Agile, c'est la raison initiale pour laquelle notre mouvement a été appelé ''Agile''. Certains d'entre nous ont également été inspirés par une [https://fansofless.com/a-realistic-and-useful-vision-of-scrum/ vision réaliste et utile de Scrum]. Mais les termes ''Agile'' et ''Scrum'' sont généralement tordus pour signifier quelque chose d'incompatible avec cette première intention, en particulier dans les organisations qui sont plus grandes qu'une équipe.<br/>
+
[[Fichier:Fans-of-LeSS-logo-white-background-596x337.png|left|100px|link=]]Nous appelons B.S. (''bullshit'') ce qui est généralement vendu comme de l'Agile et du Scrum. Nous aimons les [https://agilemanifesto.org/iso/fr/manifesto.html quatre valeurs (fr)] et les [https://agilemanifesto.org/iso/fr/principles.html douze principes (fr)] du Manifeste Agile, c'est la raison initiale pour laquelle notre mouvement a été appelé ''Agile''. Certains d'entre nous ont également été inspirés par une [https://wikiagile.cesi.fr/index.php?title=Retour_%C3%A0_une_vision_r%C3%A9aliste_et_utile_de_Scrum_(selon_Michael_James) vision réaliste et utile de Scrum (fr)]. Mais les termes ''Agile'' et ''Scrum'' sont généralement tordus pour signifier quelque chose d'incompatible avec cette première intention, en particulier dans les organisations qui dépassent la taille d'une équipe.<br/>
 
<br/>
 
<br/>
 
Les organisations traditionnelles ne gagneront pas en agilité avec le ''changement de décor'' qui est souvent vendu comme "Agile". Ce changement de décor est sérieusement contre-productif et vaccine les organisations contre les changements structurels et stratégiques dont elles auraient besoin.<br/>
 
Les organisations traditionnelles ne gagneront pas en agilité avec le ''changement de décor'' qui est souvent vendu comme "Agile". Ce changement de décor est sérieusement contre-productif et vaccine les organisations contre les changements structurels et stratégiques dont elles auraient besoin.<br/>
Ligne 20 : Ligne 23 :
 
Même lorsque plusieurs équipes sont impliquées, la capacité à s'adapter peut être très fine, sur une échelle temporelle d'une semaine à un mois plutôt que limitée à des incréments d'une épaisseur de plusieurs mois dans le cadre d'un programme et d'objectifs trimestriels.<br/>
 
Même lorsque plusieurs équipes sont impliquées, la capacité à s'adapter peut être très fine, sur une échelle temporelle d'une semaine à un mois plutôt que limitée à des incréments d'une épaisseur de plusieurs mois dans le cadre d'un programme et d'objectifs trimestriels.<br/>
 
<br/>
 
<br/>
Dans le travail de la connaissance, les "dépendances" ne sont pas causées par des lois immuables de la physique. Ressentir le besoin de planifier plusieurs sprints autour de ces dépendances est le symptôme d'une structure organisationnelle, d'une stratégie et de compétences obsolètes. Ceci devrait être abordé directement plutôt qu'être institutionnalisé avec une gestion ''waterfall'' de la dépendance qui se déguise sous la forme d'une mise à l'échelle de l'Agile.<br/>
+
Dans le travail du savoir, les "dépendances" ne sont pas causées par des lois immuables de la physique. Ressentir le besoin de planifier plusieurs sprints autour de ces dépendances est le symptôme de l'obsolescence d'une structure organisationnelle, de la stratégie et des compétences. Ceci devrait être abordé directement plutôt qu'être institutionnalisé avec une gestion ''waterfall'' de la dépendance qui se déguise sous la forme d'une mise à l'échelle de l'Agile.<br/>
 
<br/>
 
<br/>
 
L'auto-organisation par et pour l'équipe implique une structure organisationnelle simplifiée et désintermédiée. Les équipes sans rôle se coordonnent directement avec les autres équipes et apprennent directement de l'interaction avec le client. S'il vous plaît, arrêtez de réétiqueter les traditionnels spécificateurs et coordinateurs avec des noms à consonance Agile.<br/>
 
L'auto-organisation par et pour l'équipe implique une structure organisationnelle simplifiée et désintermédiée. Les équipes sans rôle se coordonnent directement avec les autres équipes et apprennent directement de l'interaction avec le client. S'il vous plaît, arrêtez de réétiqueter les traditionnels spécificateurs et coordinateurs avec des noms à consonance Agile.<br/>
Ligne 28 : Ligne 31 :
 
* supprimer les couches intermédiaires et les intermédiations inutiles (par exemple, [https://seattlescrum.com/downloads/Why-Scrum-Isnt-Making-Your-Organization-Very-Agile-Product-Owner-Misconceptions.pdf les personnes mal étiquetées "Product Owners" qui ne sont en fait propriétaire que d'une seule équipe au lieu de la totalité du produit])
 
* supprimer les couches intermédiaires et les intermédiations inutiles (par exemple, [https://seattlescrum.com/downloads/Why-Scrum-Isnt-Making-Your-Organization-Very-Agile-Product-Owner-Misconceptions.pdf les personnes mal étiquetées "Product Owners" qui ne sont en fait propriétaire que d'une seule équipe au lieu de la totalité du produit])
 
* supprimer la séparation inutile des rôles imposée par le processus (par exemple,  divers types cryptés de chefs de projets)
 
* supprimer la séparation inutile des rôles imposée par le processus (par exemple,  divers types cryptés de chefs de projets)
* supprimer les outils logiciels qui impavtent la façon dont les équipes gèrent leurs Backlogs Produit et leurs Backlogs de Sprint
+
* supprimer les outils logiciels qui impactent la façon dont les équipes gèrent leurs Backlogs Produit et leurs Backlogs de Sprint
 
* supprimer cette obsession des indicateurs chiffrés
 
* supprimer cette obsession des indicateurs chiffrés
 
* apprendre à détecter d'autres pratiques traditionnelles rebaptisées et déguisées en "Agile".
 
* apprendre à détecter d'autres pratiques traditionnelles rebaptisées et déguisées en "Agile".
En 2001, alors qu'il participait à l'élaboration du [https://agilemanifesto.org/ Manifeste Agile], Alistair Cockburn a fait une observation qui résonne toujours :<br/>
 
<br/>
 
Ce qui m'intéresse, c'est de repousser la grosse armée méthodologique, la marée de vendeurs de RUP, SEI, etc. qui placent des idées dans la tête des responsables informatiques qui devraient mettre en place une bureaucratie considérable pour être "en sécurité". Je suis contre cette mentalité du "Je veux une méthodologie clé en main, une méthodologie qui fonctionne dès que je la déballe". Voilà, ce sont les deux batailles dans lesquelles je pourrais avoir besoin d'aide.<br/>
 
 
<br/>
 
<br/>
 +
En 2001, alors qu'il participait à l'élaboration du [https://agilemanifesto.org/iso/fr/manifesto.html Manifeste Agile], Alistair Cockburn a fait une observation qui résonne toujours :<br/>
 +
Ce qui m'intéresse, c'est de repousser la grosse armée méthodologique, la marée de vendeurs de RUP, Anderson, SEI, etc. qui placent des idées dans la tête des responsables informatiques selon lesquelles ils devraient mettre en place une importante bureaucratie pour être "en sécurité". Je suis contre cette mentalité du "Je veux une méthodologie clé en main, une méthodologie qui fonctionne dès que je la déballe". Voilà, ce sont les deux batailles dans lesquelles je pourrais avoir besoin d'aide.
 
Nous soutenons des approches telles que LeSS qui sont basées sur les principes fondamentaux de l'Agile parce qu'elles peuvent mieux servir les clients et les employés. Nous rejetons les approches de "mise à l'échelle" qui augmentent la complexité organisationnelle et la dé-responsabilisation des équipes.<br/>
 
Nous soutenons des approches telles que LeSS qui sont basées sur les principes fondamentaux de l'Agile parce qu'elles peuvent mieux servir les clients et les employés. Nous rejetons les approches de "mise à l'échelle" qui augmentent la complexité organisationnelle et la dé-responsabilisation des équipes.<br/>
 
<br/>
 
<br/>
Ligne 40 : Ligne 42 :
 
* Michael James (MJ), Seattle, WA, 3 Aug 2019
 
* Michael James (MJ), Seattle, WA, 3 Aug 2019
 
* Manoj Vadakkan, Denver, CO, 3 Aug 2019
 
* Manoj Vadakkan, Denver, CO, 3 Aug 2019
* [https://fansofless.com/how/ Ajoutez votre nom !]
+
* [https://wikiagile.cesi.fr/index.php?title=Comment_rejoindre_Fans_of_LeSS_%3F Ajoutez votre nom !]
* ...
+
* [https://fansofless.com/#signatories liste des signataires]

Version actuelle datée du 3 août 2020 à 05:42

Auteur : © 2019 Fans of LeSS
Source : fansofless.com
Date : 03/08/2019


Traducteur : Fabrice Aimetti
Date : 17/08/2019


Traduction :

Fans-of-LeSS-logo-white-background-596x337.png
Nous appelons B.S. (bullshit) ce qui est généralement vendu comme de l'Agile et du Scrum. Nous aimons les quatre valeurs (fr) et les douze principes (fr) du Manifeste Agile, c'est la raison initiale pour laquelle notre mouvement a été appelé Agile. Certains d'entre nous ont également été inspirés par une vision réaliste et utile de Scrum (fr). Mais les termes Agile et Scrum sont généralement tordus pour signifier quelque chose d'incompatible avec cette première intention, en particulier dans les organisations qui dépassent la taille d'une équipe.


Les organisations traditionnelles ne gagneront pas en agilité avec le changement de décor qui est souvent vendu comme "Agile". Ce changement de décor est sérieusement contre-productif et vaccine les organisations contre les changements structurels et stratégiques dont elles auraient besoin.

Les organisations Agile apprennent, redéfinissent les priorités et s'adaptent à l'évolution des besoins des clients, plutôt que de se concentrer sur la quantité produite.

Même lorsque plusieurs équipes sont impliquées, la capacité à s'adapter peut être très fine, sur une échelle temporelle d'une semaine à un mois plutôt que limitée à des incréments d'une épaisseur de plusieurs mois dans le cadre d'un programme et d'objectifs trimestriels.

Dans le travail du savoir, les "dépendances" ne sont pas causées par des lois immuables de la physique. Ressentir le besoin de planifier plusieurs sprints autour de ces dépendances est le symptôme de l'obsolescence d'une structure organisationnelle, de la stratégie et des compétences. Ceci devrait être abordé directement plutôt qu'être institutionnalisé avec une gestion waterfall de la dépendance qui se déguise sous la forme d'une mise à l'échelle de l'Agile.

L'auto-organisation par et pour l'équipe implique une structure organisationnelle simplifiée et désintermédiée. Les équipes sans rôle se coordonnent directement avec les autres équipes et apprennent directement de l'interaction avec le client. S'il vous plaît, arrêtez de réétiqueter les traditionnels spécificateurs et coordinateurs avec des noms à consonance Agile.

Dire oui à l'agilité, c'est dire non aux choses que l'on qualifie à tort d'Agile. Voici ce que nous pouvons faire à la place :


En 2001, alors qu'il participait à l'élaboration du Manifeste Agile, Alistair Cockburn a fait une observation qui résonne toujours :

Ce qui m'intéresse, c'est de repousser la grosse armée méthodologique, la marée de vendeurs de RUP, Anderson, SEI, etc. qui placent des idées dans la tête des responsables informatiques selon lesquelles ils devraient mettre en place une importante bureaucratie pour être "en sécurité". Je suis contre cette mentalité du "Je veux une méthodologie clé en main, une méthodologie qui fonctionne dès que je la déballe". Voilà, ce sont les deux batailles dans lesquelles je pourrais avoir besoin d'aide.

Nous soutenons des approches telles que LeSS qui sont basées sur les principes fondamentaux de l'Agile parce qu'elles peuvent mieux servir les clients et les employés. Nous rejetons les approches de "mise à l'échelle" qui augmentent la complexité organisationnelle et la dé-responsabilisation des équipes.

Signataires :