Le burn de l'agilité

Je suis en désaccord avec votre croyance à tous les deux, ce qu’avant je croyais aussi… et je m’explique : sans apport extérieur, en laissant suffisamment de temps, toute structure gagne en chaos. C’est l’entropie de l’information des systèmes fermés ou juste un peu poreux.

C’est en systémie le concept des « tentatives de solution » : « les problèmes viennent des solutions » (citation de Bateson, de souvenir) que le système met en place, pensant qu’elles sont bonnes.

C’est d’ailleurs ce que je vais proposer dans une future conf (ça fait longtemps que j’ai envie de le faire) et de destructurer le Kaizen à outrance, qui au bout d’un moment ne peut plus être « bon » (zen) sans changement brutal (kaku), et c’était d’ailleurs la logique de la création du TPS (Toyota Production System). Quand on regarde les changements de système forts qu’il y a eu, c’était en très très grande majorité brutal. Toyota est un bel exemple avec les Kaikaku oubliés de l’histoire.

Et par rapport au dernier message, je dirais même plus : un Scrum Master apprend à l’équipe à désapprendre :wink:

3 « J'aime »

On pourrait aller loin dans ce chemin, mais je te dirais que la première marche, c’est d’apprendre qu’on ne sait rien, donc on reste dans l’apprentissage quand même x)

1 « J'aime »

L’un des plus grand oubli de la communauté, indeed.

c’est pour cela qu’en intro je dis je tends à être agile, quand tu es conscient des blokers tu fais autrement, tu prends du recul et tu évites de burner tous les 6 mois, du moins c’est comme cela que je trouve mon équilibre de vie pro ce qui est bénéfique côté perso. Mon avis est que si tu fais de l’agile dans un monde qui ne l’ai pas cela n’est pas bon pour ta santé mentale → burn…

3 « J'aime »

Je crois que j’ai ouvert la boite de Pandore par mes questionnements personnels :wink: Merci des débats et des feedbacks ! Je préfère une sincérité réelle et sans blessure à autrui qu’une fausse bienveillance.

2 « J'aime »

C’est normal. Un système (et quand je dis système, c’est surtout d’un « corps » dont je parle) agile est plus soumis à des états de stress parce que c’est sa manière de survivre à son environnement. Une baleine est pas agile parce qu’il n’en va pas de sa survie. En contrepartie, son métabolisme réagi lentement aux agressions extérieurs. Le coût de l’agilité reste quand même la quantité immense d’énergie mise en œuvre autant du côté musculaire que du côté « vision ». Et si tu crame toute cette énergie pour rien, ben… :upside_down_face:

Moi je trouve ça salutaire au contraire. Les trucs où tout le monde est d’accord, ça me lourde… :smiley:

1 « J'aime »

Aïe aïe Thibaut,

D’après ce que tu m’expliques c’est que on ne donne pas les outils nécessaires à l’équipe pour acquérir une réelle autonomie technique, d’où se sentiment d’abandon.
Le SCM a quand même une part de responsabilité, en tant que coach humain, sur ce sentiment de tourner en rond.
Non pas qu’il doit prendre des décisions techniques, mais insuffler une méthodologie de résolution de problèmes (proposer de faire des MVP exploratoires, prendre du recul sur le contexte de fonctionnement, faire amener l’équipe à exprimer un besoin à remonter à l’organisation : un senior techlead, une prise d’informations/formations extérieures).
La monté en compétence et l’autonomie se n’est pas inné, elle doit être accompagnée.

1 « J'aime »

Le pouvoir ne se donne pas, il se prend.

@BenjaminF En effet toute révolution est un moment de rupture qui chamboule car à des degrés divers elle fait sortir de sa zone de confort. Mais bien accompagné, elle peux créer de l’engouement, mal accompagnée elle créera de la frustration.

@Samuel_Abiassi , Je n’ai pas comme première impression que dans le cas présent il y a un problème de rapport de force.

1 « J'aime »

on ne donne pas les outils nécessaires à l’équipe pour acquérir une réelle autonomie technique, d’où se sentiment d’abandon.

J’aurai plus vue ça comme un Syndrome de Stockholm. A vivre depuis des années avec un build aléatoire, des machines de test qu’il faut reboot régulièrement, des flacky test qu’il faut relancer 2 ou 3 fois jusqu’à ce qu’ils passent, l’équipe ne se rendait même plus compte que cet état de fait n’était pas normal :smiley: .

C’est là ou je rejoint @BenjaminF , ce type d’équipe ne peut pas s’en sortir seul.

1 « J'aime »

Y’a toujours un rapport de force. Après, on peut certes fermer les yeux sur cet état de fait mais bon.

Ah et aussi… Peut-on tous se mettre d’accord pour arrêter de dire que l’agilité est un mindset ? Je vous en supplie, par pitié…

1 « J'aime »

Le mindset n’est-il pas quand même un pré -requis ?

Ne sert-il pas à préparer l’ esprit à connaître, puis comprendre puis appliquer les valeurs, les principes et les pratiques agiles ?

Si on n’a pas le « mindset agile », métonymie qui engloberait pour moi une préparation de l’esprit à casser les barrières psychologiques liées à la culture séculaire du taylorisme, peut on mettre en œuvre les pratiques agiles dans le respect des valeurs et principes agiles ?

Le mindset, pour toi, c’est quoi ?
C’est la pensée ?

Dans les concepts de changements en thérapie :

  • Dans la systémie, le changement vient par un changement d’émotion lié à un nouveau comportement, généralement à l’inverse des solutions et idées de la personne. Présupposé : « le changement ne vient que par un nouveau comportement »
  • Dans la TCC, c’est soit en changeant la pensée ou le comportement qui permet de changer l’émotion. Présupposé : « de nos pensées viennent les comportements et émotions »

Quand on regarde ça, ce n’est pas forcément le mindset. C’est aussi en faisant qu’on change. De nouveaux comportements entrainent de nouvelles pensées. De nouvelles pensées entrainent de nouveaux comportements. Il n’y a pas de pré-requis, et c’est d’ailleurs le vrai Shu-ha-ri, c’est très pragmatique :

  • Shu : suivre la règle (juste les fondamentaux) et donc j’agis
  • Ha : casse la règle car je la comprends
  • Ri : Devient la règle
3 « J'aime »

Sans parler des causes exogènes et tout le toutim oui.

La pensée je ne sais pas, ça me semble un terme trop général qu’il faudrait préciser
Comme je dis le mindset pour moi c’est une préparation de l’esprit à un changement substanciel qui va toucher aux valeurs portées dans le travail, jusqu’aux pratiques.

Pour certaines personnes, comme j’imagine vous et moi, le changement des pratiques est probablement solvateur, au fond de nous on l’attendait. Donc le mindset, l’état d’esprit apte à accepter les pratiques agiles on l’a.
Pour d’autres c’est plus compliqué
Et je peux comprendre que la pratique aide les personnes à se faire leur propre idée, que ces pratiques amènent des résultats. Mais parfois et même de manière souvent fréquente, malgré les résultats, des personnes n’auront jamais ce mindset, évoquant le fruit du hasard, de la chance, du contexte favorable, parce que l’état d’esprit apte à ce changement n’est pas ancré en eux et je pense, pour ma part, que ce sont ces personnes qui appliquent l’agile sans avoir l’esprit pour (le mindset donc) et qui font que des coachs ou scrum finissent par se démotiver comme tu l’évoques dans ton message initial

  • bon désolé c’est peut-être un peu décousu mais je souhaitais apporter ma graine à cette riche et intéressant conversation :slight_smile:
4 « J'aime »

Très vrai ce que tu dis !

La théorie sans la pratique est inutile, et la pratique sans la théorie est aveugle - Kant

On en revient à ça :wink: Le mindset n’est donc pas suffisant pour avoir des résultats. Tu peux avoir le mindset mais ne pas pratiquer, par exemple un Scrum Master qui comprend totalement Scrum mais qui ne sait pas l’expliquer et adapter sa propre communication à son public. Et ça ne sera pas efficace !

Et donc, « il faut » les deux : la théorie (mindset) ET la pratique. L’un n’entraine pas forcément l’autre.

4 « J'aime »

Excellente citation, je la retiens celle la, ça change des gourous du product :grin:

1 « J'aime »