toltequeagile.com est un site de Thierry Cros Organisation

Toltèque Agile

1 2 3 Catégorie Billets Agile Voie Toltèque

Formation Leading SAFe 10 11 juin 2019 Toulouse

21/04/2019

Formation Leading SAFe 10 11 juin 2019 Toulouse

Une formation intense au cœur de Toulouse, à deux pas du métro.

 

  • Un tarif raisonnable. Halte à la surenchère !
  • Un contenu réellement parcouru : toutes les (nombreuses !) planches du support officiel sont passées en revue, pour une préparation complète à la certification "SAFe Agilist'.
Utilisez la page "Contact" pour demander plus de renseignements.

Coach Extreme Programming et SAFe Program Consultant

04/02/2019

Coach Extreme Programming et SAFe Program Consultant

L'agile mute, ce qui est dans la nature d'un système de croyances. Mais Robespierre vint après Danton et des ayatollahs, stakhanovistes et autres aficionados constituent aujourd'hui les gardiens de la bien-pensance agile.

#NotInMyName

 

Cet article fait suite à d'autres tels que Agile : deux filiations et bien d'autres.

 


Les ayatollahs de l'anti-SAFe

Leur passe-temps consiste à balancer des fatwas contre ce cadre d'agile à l'échelle. Certains lui reprochent son business model (oui c'est aussi une pompe à fric...) hérité de celui de Scrum.

Ou bien ce côté "échelle", que l'on ne reprochait pas à LeSS 10 ans plus tôt. Bref, si je mets de côté le procès d'intention, l'ignorance, le conservatisme... Il ne reste plus beaucoup d'arguments contre SAFe. 

Les chiens aboient, la caravane SAFe passe.

 

 

Les Stakhanovistes du Big Visible Information Radiator

Allez, je reprends le terme SAFe pour Management visuel. Ceux, collègues ou Clients, qui ont travaillé avec moi savent mon attachement à cet outil fondamental d'une approche XP ou SAFe.

Mais ce n'est pas le seul et bon nombre d'organisations ont réellement besoin d'informatiser les artefacts de ces approches : stories, epics... C'est ainsi. Vivons avec notre temps :)

 


Les Aficionados de l'entreprise délivrée

Oups.. Libérée...  Mais c'est un peu la faute de ces "reines des neiges" qui ne jurent  plus que par mindfulness, communication nonviolente ou intelligence émotionnelle.

Je pense avoir été un des premiers, dès 2003, à montrer l'importance de ces soft-skills dans une équipe qui pratique l'Extreme Programming ou aujourd'hui SAFe. Voir mon premier livre "Maîtrisez les projets avec l'Extreme Programming" dans lequel je consacre un paragraphe à "Les accords toltèques : une éthique de communication pour une équipe XP". (Et oui, à l'époque je parlais encore de "projet" !)

Mais ceci n'est pas le fondement !

Itérations courtes et intégration continue, auto-amélioration par PDCA... Autant de fondamentaux aujourd'hui négligés dans les  présentations de rôles de Scrum par exemple.

Un peu comme si la couleur de la tapisserie était le sujet important alors que les fondations ne sont pas sèches...

 


Bref... Je suis Coach XP et SPC

Et je peux vous dire que j'en suis fier :)

Allez, sans rancune l'agile, tu m'auras fait rêver, tu m'auras fait avancer, tu m'auras donné du taf pendant plus de 15 ans. Et je t'aurai  donné aussi du temps, de l'attention, de l'enthousiasme.

Mais je préfère, aujourd'hui comme hier, être au contact des organisations, bleues pour la plupart dans la spirale dynamique, et avancer avec les outils actuels, audibles et efficaces.

Je ne suis plus "coach agile". Je suis encore et toujours Coach XP (versions fréquentes, user stories, tests d'acceptation, planning game, intégration continue, Test 1st Programming...) et SAFe Program Consultant.

Agile : deux filiations

14/01/2019

Agile : deux filiations

Fin des années 90, apparait un cadre révolutionnaire : l'Extreme Programming. Ses fondements sont

  • Lean Development
  • Lean Manufacturing
  • Scrum
  • Puissances des matériels et environnements de développement
  • crise récurrente du logiciel.
Et l'Extreme Programming colore très fortement le Manifeste agile en 2001.
Le cadre Lean se caractérise par une finalité que l'on retrouve dans le premier principe agile. Un certain équilibre valeur et qualité (au sens maintenabilité).
L'équipe auto-organisée, l'amélioration continue... sont des piliers de cette approche.
Si je considère par exemple différentes techniques de priorisation de besoins, mon discriminant principal est : est-ce que cette priorisation optimise la valeur ?
Par ailleurs, Scrum est une coquille vide, ce qui en fait à la fois sa force et sa faiblesse. Le backlog est priorisé, ce qui autorise, entr'autres... une optimisation de valeur. La qualité est directement fonction de la "definition of done" apparue début des années 2000. Intention louable, certes. Mais est-elle si ambitieuse ? Si en tant que Développeur je ne connais pas ou je n'achète pas le code propre, qu'en est-il de la maintenabilité, quand bien même la DoD est respectée.
Cadre vide, pas de ligne vraiment directrice... du coup, nous faisons feu de tout  bois. Mindfulness, le dieu postit, voire cosplay... Un peu comme si nous nous occupons de la qualité de la tapisserie alors que la fondation n'est pas sèche...
La maison Lean, telle que décrite par exemple dans SAFe, permet de mieux comprendre cette différence de point de vue.
Une autre maison proposerait l'auto-organisation, le bonheur au travail, l'entreprise libérée (du management, du capitalisme sauvage... ?) comme toit, comme finalité.
Pourtant, l'agile pose clairement l'avantage concurrentiel comme objectif.  Attention donc à ne pas confondre but et moyen.
Sur le Titanic, certains rêvaient du Nouveau Monde.
D'autres, désespérément optimistes, s’efforçaient de sauver le navire.

Le Manager dans un PI planning

13/11/2018

Le Manager dans un PI planning

Je participais récemment à une formation SAFe Agilist (Leading SAFe). Pendant la simulation de PI planning, une question :

Les Managers sont-ils invités à cet événement phare de SAFe ?

Il est vrai que SAFe, comme d'autres cadres agiles, ne prend pas spécialement en compte les Managers. Sauf que le Lean Portfolio Management, le rôle de Business Owner sont autant de possibilité d'intégration naturelle dans le dispositif.

 

Mon expérience est que les Managers ont tout intérêt à participer activement à un PI planning, cela pour trois raisons.


1. Montrer leur sponsoring, leur intérêt

La transparence est l'une des quatre valeurs "cœur" de SAFe. Rien ne s'oppose donc à la présence des Managers.

Être présent est un signe fort : le Manager a "casé" le PI planning dans son agenda, il considère cela suffisamment important pour lui consacrer du temps.

Il peut ainsi, soit au micro, soit en aparté, sponsoriser l'événement et au-delà le passage stratégique à l'agile. Évidemment, si le business context d'introduction est présenté par un Manager, la question ne se pose plus.


2. Management Review

Le PI planning contient explicitement une revue par le Management. On peut arguer qu'il ne s'agit pas de "Manager Review"....

Pourtant, il s'agit ici d'ajuster les variables du plan (plan du PI) en fonction des inéluctables variables : budget, planning, contenu, dette technique, respect des personnes.Si le Product Management peut décider du changement de contenu, les questions budgétaires, les ajustements de planning nécessitent parfois l'intervention d'un Manager, par exemple lorsque celui-ci est dans un rôle de Business Owner.

Cas classique : "autoriser" officiellement un refactoring.

C'est d'autant plus vrai lorsque des Développeurs dans les équipes sont des sous-traitants. Dans ce cas-là, la présence d'un Manager côté sous-traitance est à mon sens obligatoire.

 

3. Auto-organisation : je t'aime... moi non plus

Last but not least, SAFe, via le principe de décision décentralisée, prône aussi l'auto-organisation. Sauf que ce n'est pas si simple.

Sans tomber dans l'extrême type USA chez qui un sous-traitant, par peur d'être viré avant midi, ne va pas s'engager lors d'un stand-up (expérience vécue) le fait est que l'autonomie des équipes est un changement culturel si profond qu'il faut du temps pour l'acter.

Du coup, le Manager est là pour, encore une fois, faire passer le message :

Mais oui, c'est bien à vous de décider, de vous engager...

 

Ne venez pas vous plaindre du manque d'implication du Manager si celui-ci ne participe pas à la vie du train car il n'y est pas convié !

 

Autant de raisons d'inviter les Managers au prochain PI planning.

C'est si simple :)

Manifeste de la voie toltèque

14/10/2018

Manifeste de la voie toltèque

La voie toltèque, comme l'agile, est empirique, basée sur une expérience concrète et personnelle.

Nous sommes donc loin des dogmes qui supposent une foi aveugle.

Tout comme l'agile, la voie toltèque offre des pratiques qui permettent de se forger sa propre expérience.

 

 

Impeccabilité plutôt que réaction

Autrement dit, être proactif et ne pas utiliser la parole contre soi, plutôt qu'être dans une réaction habituelle, non maîtrisée.

 

 

Moi authentique plutôt que parasite

Qui parle, qui pense...

 

 

Ancrage au corps plutôt que flot de pensée

Ce qui ne veut pas dire qu'il ne faut jamais penser...

 

 

Amour plutôt que peur

Peur ou déclinaisons : tristesse, colère...

 

 

 

 

 

 

SAFe : la rétro

13/10/2018

SAFe : la rétro

Je voudrais préciser avant de démarrer que je suppose connue la page de présentation des valeurs "coeur" de SAFe.

Sinon, nous ne parlons pas de la même chose.

 

Je me souviens de mes premiers pas en SAFe. Cela devait être en 2013. J'avais été rebuté par le côté "usine à gaz" de la page d'accueil. Pourtant, lorsque j'évoquais ce cadre avec le directeur technique qui était mon client, cela lui parlait et le motivait pour une mise en place, alors que nous étions en train de le réinventer en terme de portfolio Kanban et de programme sous-jacent. Cela m'a mis la puce à l'oreille.

Du coup, je me suis penché plus sérieusement sur le sujet. Et j'ai découvert de bien belles propositions. Pilotage par Cost of Delay, macro-itérations (program incrément) pour cadencer l'ensemble... Fallait oser.

Je retrouvais aussi une culture Extreme Programming.

Normal.

Les deux s'inscrivent clairement dans une filiation Lean (manufacturing et development).

SAFe devenait alors pour moi un beau cheval de Troie pour faire véritablement de l'agile comme Scrum quelques années plus tôt. SI ce n'est que SAFe est intrinsèquement beaucoup plus agile que Scrum.

 

Si le framework souffre de quelques pratiques obsolètes (par exemple la description du plan d'itération qui dure 4 heures.. !) c'est surtout l'implementation roadmap qui me parait "grave chelou".

D'une part mon constat est que SAFe s'adresse au équipes, petites ou grandes, qui présentent bien les trois niveaux

  • Portfolio
  • Programme
  • Team
le discriminant n'est pas le nombre de personnes.
D'autre part, j'insiste beaucoup dans mes accompagnements sur la co-construction de l’implémentation, ce qui SAFe n'interdit pas, bien sûr, mais ne met pas suffisamment en avant à mon goût.
Contrairement à ce que préconise l'implementation roadmap, je propose de démarrer avec les trois niveaux, ce qui a le mérite d'embarquer plus de monde dans le changement et facilite le premier PI planning.
Ce qui fonctionne...
Les concepts proposés par SAFe sont pertinents et "parlent" aux équipes.
  • Business Epic
  • Capability
  • Feature
  • Story.
Ils permettent de bien conceptualiser la situation en termes de niveaux d'abstraction. Ce qui évite de tomber dans le piège du gros stock (de stories ou features par exemple).
Les activités : product management, architecture... sont vraiment utiles pour embarquer les rôles actuels, selon les trois niveaux et les trois collèges (besoin, solution, soutien).
Les artefacts de pilotage, les tableaux Kanban de business epics et features sont particulièrement utiles.
Le calcul du CoD est un vrai bonheur pour retrouver un pilotage par la valeur et ne pas retomber dans des biais cognitifs rendus possible par une "priorisation" de backlog.

Ce qui patine un peu (beaucoup)...
Si SAFe insiste sur la qualité intrinsèque et rappelle que l'objectif n'est pas uniquement la valeur à tout prix, il reste que "faire de la m..." est tellement ancré qu'il faudra du temps pour réifier cette valeur de SAFe et les pratiques sous-jacentes issues de l'Extreme Programming : Test First Programming, refactoring, conception émergente. Attention, tout le monde est concerné, du manager qui y voit un risque de sur-qualité (Oh mon Dieu, comment peut-on parler de sur-qualité dans notre domaine...) au Développeur qui veut absolument le schéma complet de la base de données pour être tranquille...
Les décisions décentralisées et l'auto-organisation d l'équipe... It"s a long way... Je ne remercie pas  Scrum et son satané scrummaster omniprésent... Pas facile de lâcher-prise d'un côté, de prendre conscience de ce plus d'autonomie de l'autre.
La question des outils... Sans être rédhibitoire, elle pose quand même question. Comment faciliter la vie du collège besoin sur les trois niveaux ?
Idées
Une première idée est de recentrer la transfo sur la valeur "program execution".
Une autre est revenir régulièrement sur les 4 valeurs et principes du mindset, qui constituent la fondation de la maison Lean-SAFe.
Gratitude
Je tiens donc à exprimer ma gratitude envers les concepteurs de SAFe, même si cette gratitude n'est pas aveugle. Beau boulot !
Gratitude aussi envers les membres de la communauté agile qui, loin de tout dogmatisme, considèrent objectivement SAFe, les forces et faiblesses du framework.
Gratitude aussi envers les "pro-SAFe" qui se souviennent que la qualité fait bel et bien partie du framework. Ils ne sont pas si nombreux...
Gratitude enfin envers mes clients qui me démontrent chaque jour que ce framework est utile et... agile.

En guise de conclusion...

SAFe n'est certainement pas la solution magique à la question de l'agile à l'échelle. En existe-t-il une d'ailleurs .? Je ne crois pas à un dispositif qui serait suffisamment universel pour répondre à toutes les demandes. Cela dit, si vous en connaissez un, faites moi signe, ça m'intéresse :)

 

Je regrette le côté dogmatique de postures anti-SAFe qui s'apparente un peu aux antifas. Ils finissent par présenter les symptômes de ce qu'ils sont censés combattre...

Ils sont plus des procés d'intention de personnes qui n'ont pas compris ce qu'est l'agile ou du moins qui en sont restés à une vision aujourd'hui obsolète de ces disciplines empiriques. Ou encore qui confondent fin et moyen.

Les retours d'expérience particulièrement négatifs de passage aux entreprises libérées (délivrées...)à l'agile...  à la schlague  via des forums ouverts et autres pratiques hors sol devraient inciter à plus de modération.

 

Mais ne jetons pas le bébé avec l'eau du bain.

SAFe est particulièrement adapté aux organisations, petites ou grandes, qui restent dans une gouvernance classique, de type hiérarchique. SAFe parle leur langage tout en amenant l'agile. C'est un très beau cheval de Troie qui permet de poser la qualité intrinsèque, l'alignement, le pilotage par la valeur..  au cœur du sujet.

SAFe "autorise" les décisions décentralisées, l'auto-organisation. SAFe rassure le management qui retrouve le portfolio, la question budgétaire... SAFe est une révolution agile pacifique, audible dans les organisations aujourd'hui.

 

L'agile est-il scalable ?

11/10/2018

L'agile est-il scalable ?

Avant de plonger dans ces douze principes qui définissent ce qu'est l'agile, je voudrais préciser ce qu'est un principe, à mon sens, empreint du canal historique "XP".

 

Kent Beck dans je ne sais plus quel livre dessine un pont qui représente un principe, entre valeur et pratique.

 

Contrairement à une pratique, un principe 'est moins contraint par le contexte. Il est plus "universel".

Le feedback dans XP est érigé en valeur, comme la communication ou la simplicité.

Cela signifie que le feedback est une  croyance suffisamment structurante pour colorer notre perception d'une situation... et notre réponse à cette situation. Dans cet ordre d'idée, le "process" est aussi une valeur pour certains.

"Feedback concret et rapide" est un principe important de l'Extreme Programming.

Il fait le pont entre la valeur et de nombreuses déclinaisons en pratiques.

  • Pair programming : feedback d'un pair sur le développement
  • TDD : feedback de tests pour assurer la correspondance conception/codage
  • test d'acceptaton
  • stand up
  • versions fréquentes
  • ...
Notez d'ailleurs que la plupart des principes agiles sont des généralisations de pratiques XP.
Le principe est important car il explique, justifie, la pratique.
Et il permet d'adapter la pratique lorsque ses "préconditions" ne sont pas remplies.
On voit donc qu'un principe a beaucoup moins de contraintes qu'une pratique.
Les 12 principes agiles seraient-ils à ce point si dépendants du contexte d'une petite équipe ?
Le contexte a naturellement une influence sur la mise en œuvre des principes. Par exemple la conception émergente n'a pas le même sens  suivant la taille de l'appli. Pour autant, rien n'empêche cette conception, dans le cadre d'une architecture intentionnelle de SAFe,
la vraie question est plutôt :
  • l'intérêt d'une conception émergente est-il clair ?
  • Les architectes/développeurs sont-ils à l'aise avec ?
  • L'étage portfolio sponsorise-t-il  ce type d''architecture ?
Ce n'est pas parce que les premiers cadres et méthodes agiles étaient "conçus" pour des petites équipes que les principes agiles sont limités et ne peuvent pas s'adapter à l'échelle.

Question de culture... Ou pas

09/10/2018

Question de culture... Ou pas

J'ai cru pendant longtemps qu'il fallait changer la culture ou même qu'un non-changement de culture était rédhibitoire dans la mise en oeuvre de l'agile.

C'est une planche des formations SAFe (et oui, je suis certifié SPC et donc j'en profite pour (co-)animer des formations !) qui m'a permis d'exprimer ce que je ressentais confusément jusqu'alors à propos  des pro et anti SAFe.

Allez savoir pourquoi... Si j'étais au départ plutôt rebuté par ce cadre d'agile à l'échelle, j'ai fini par comprendre son intérêt.

 

La clé est dans le premier pilier de la maison Lean vue depuis SAFe.

 

 

"Culture change comes last, not first".

Je crois que c'est ce qui est fondamentalement agile dans SAFe : le framework respecte les cultures tout en donnant un sacré coup de pied dans l'organisation.

Et c'est pour cela que ça marche.

Et c'est pour cela que parfois les mises en œuvre de Scrum ne marchent pas : si l'intention reste louable, elles ignorent la culture et les personnes en imposant a priroi un changement culturel impossible à atteindre.

Par exemple en remettant en cause la pertinence du rôle de Manager.

Ou bien en oubliant la nécessité d'outils informatisés.

Ou encore en confondant la finalité : meilleur équilibre valeur-qualité (cf le toit de la maison Lean) et le moyen : l'auto-organisation (décision décentralisée).

 

En dernière analyse, c'est une question de posture, voire d’ego.

Soit je vois l'agile de mon point de vue, soit du point de vue du.. pratiquant, dans son écosystème.

Et tout simplement une question de temps, face à des changements tout autant profonds qu'inéluctables.

Arrêtons donc de vouloir à tout prix changer les cultures, de considérer comme "échec" ce qui est déjà une incroyable avancée dans les organisations.

Arrêtons de vouloir libérer (délivrer...) des organisations qui ne sont pas prêtes.

Le management n'a pas encore changé son mindset... et alors ?!?

Comme disait ma grand-mère, "le mieux est l'ennemi du bien".

Ou encore "ne jetons pas le bébé avec l'eau du bain".

 

L'agile aujourd'hui est dans la colonne "Work in Progress" de la société.

Et c'est juste génial :)

Agile : la mitose

26/09/2018

Agile : la mitose

D'où vient l'agile ?

Certains évoquent un article des années 80 où le terme Scrum apparaît, nous pourrions aussi remonter carrément au début du Lean, oups, du Toyota(da) Production System.

Mais non, ne confondons pas agile, Scrum, Lean... et tutti quanti.

Je vous suggère la lecture de l'histoire du Manifeste agile sur ce sujet.

L'agile naît sous l'impulsion de la communauté Extreme Programming.

 

Mais... d'où vient l'Extreme Programming ?

 

Années 90 : objet et EDI

Les langages C++ puis Java vont démocratiser l'objet et ainsi décupler les possibilités du code, en particulier grâce au polymorphisme. Dans le même temps, les matériels et Environnements de Développement Intégrés gagnent en puissance. Pensée émue pour le Turbo C++...

Pour le dire autrement, XP, et donc l'agile, n'auraient pas pu exister au moment de mes premiers pas en programmation, faits de ... cartes perforées. Désormais, le cycle de développement est considérablement accéléré. De quelques heures à quelques secondes. Et ça change tout.

 

Scrum

XP s'appuie également sur le cadre Scrum, une coquille vide (c'est sa force) qui sera d'ailleurs "agilisée" par XP : client sur site, itération de 3 semaines et pas un mois, surtout adapté au développement de logiciel.  L'arrivée, un peu plus tard, de la Definition of Done, montre bien la différence d"approche, entre un cadre généraliste tel que Scrum et une méthode adaptée au logiciel (XP ou aujourd'hui SAFe). La DoD est une bonne idée, qui est fonction de la perception du produit. Si je ne sais pas ce qu'est une gestion de conf et son utilité, je ne vais pas en parler dans la DoD... Et ce sera quand même une DoD. XP met la barre très haut (c'est peut être là que se situe le problème avec l'agile...).

 

Lean Manufacturing et Lean Development

C'est certainement la source décisive de l'Extreme Programming. Le nom même est d'ailleurs typiquement Lean : focus sur l'activité qui apporte de la valeur dans le dev : la programmation. Et ce tour de force que fut le Test First Programming autrement dit le principe de qualité intrinsèque afin appliqué au code.

Et XP reprend donc le "motto" du Lean : apporter rapidement de la valeur, tout en maintenant un bon niveau de qualité (entendez "maintenabilité" en particulier). Ce que l'on retrouve dans les principes du manifeste agile.

Les étiquettes Kanban deviennent des user stories. Les activités à non valeur ajoutée directe sont limitées (par exemple l'écriture de doc qui s'avère inutile...).

Plus globalement, c'est le principe fondateur Just in Time et ses corollaires :

- petits stocks

- feedbacks plus concrets et plus rapides (un principe XP)

qui sont réifiés à différents niveaux et dans différents domaines. Du feedback  du partenaire en pair programming au feedback des Utilisateurs dans versions fréquentes, les pratiques XP sont des déclinaisons du Lean.

 

Et ainsi naît l'agile. Avec donc un objectif, un but (the goal...) : apporter rapidement de la valeur et garantir la qualité dès le développement.

Je ne peux que vous suggérer de relire le Manifeste et ses principes pour vous en convaincre.

 

Mais le cadre le plus utilisé reste Scrum, propice à l'agile sans l'être vraiment. Le backlog est priorisé... par la valeur, vraiment ? La qualité est assurée par la DoD... mais quels critères... ? C'est le prix à payer pour l'universalité de la méthode.


SAFe : l'autre saut quantique de l'agile

Les temps ont changé. L'agile est perçu comme une réponse possible à un monde de plus en plus VUCA, volatile, incertain, complexe, ambigu. Et ça tombe bien, l'agile est une discipline empirique conçue pour répondre à la complexité, la difficulté à prévoir.

SAFe reprend le flambeau, s'appuie largement sur Lean et XP. SAFe pose clairement la recherche de valeur (CoD, WSJF) et la qualité comme bases.

 

Et c'est ainsi que je me retrouve sur un chemin très peu fréquenté : une ligne de crête entre deux précipices :

- ceux qui enfilent des perles, qui préfèrent parler à longueur de journée de mille sujets, intéressants certes, mais qui sont périphériques (je ne dis pas inutiles) ;

- ceux qui soutiennent SAFe mais sans dire un mot de qualité, de TDD, etc ; qui sont  pourtant officiellement dans le framework... Peut-être par peur ou ignorance, je ne sais pas.

 

Alors que le cœur du sujet agile aujourd'hui est comme hier :comment une équipe auto-organisée apporte t elle de la valeur, de la qualité, en s'améliorant impitoyablement.

Sauf qu'aujourd'hui l'équipe c'est potentiellement plusieurs centaines de personnes.

Et c'est tant mieux !


C'est ainsi que nous nous retrouvons avec les partisans d'un agile "libéré" (délivré...)  qui matent du côté de l'entreprise libérée justement... sans manager (les méchants..). Un agile hors sol.

Ceux qui soutiennent SAFe en oubliant que la qualité est au cœur du sujet, depuis plusieurs décennies dans le Lean.

Un agile sans le saut quantique.

 

Mitose : done.

 

Ce n'est pas parce que la barre est haut placée qu'il faut renoncer.

Peu importe finalement. Le changement est en marche :). Il faudra certainement quelques décennies.

En ce moment, nous plantons des graines et c'est le plus important. Le voyage est dans le chemin, pas dans la destination.

 

"Une fois que vous vous rendez compte que le chemin est le but

et que vous êtes toujours sur le chemin non pas pour atteindre un but,

mais pour en apprécier sa beauté et sa sagesse,

alors la vie cesse d'être une tâche et devient naturelle et simple,

une extase en elle-même."
Sri Nisargadatta Maharaj

 

Portez vous bien, faites attention à vous, dites aux personnes que vous aimez...

que vous les aimez.

C'est quand même le plus important dans l'histoire.

Namasté

 

"Accueillez la vie comme elle se présente. Ne mettez pas l'accent sur le monde mais changez votre attitude à son égard. Soyez votre totalité et le monde changera."           Jean Klein

Ateliers "accords toltèques" Perpignan de septembre 2018 à janvier 2019

30/08/2018

Ateliers "accords toltèques" Perpignan de septembre 2018 à janvier 2019

Dans ces cinq ateliers (un par accord), vous découvrirez ce qu'est le Parasite, sa puissance. Surtout, vous explorerez votre impeccabilité. Vous apprendrez à utiliser le corps comme ancrage, grâce à quelques pratiques simples et très efficaces. Vous comprendrez l'importance de prendre soin de votre "Enfant Intérieur", votre Moi authentique. Vous pratiquerez l'Attention seconde. Vous pourrez utiliser quelques pratiques simples d'expression - impeccable - de  vos émotions. Vous serez parfois silencieux, c'est-à-dire sans ce flot de paroles (pensées...) incessant qui caractérise notre état.

Chaque atelier est consacré à un accord (du premier au cinquième). Nous formerons un cercle et nos travaux seront individuels, en binôme ou parfois en groupe, toujours placés sous le signe du volontariat.

Exemples de pratiques proposées :

  • Nommer votre parasite
  • sensation ambulatoire
  • communiquer avec son Enfant Intérieur
  • état des lieux de nos différentes facettes
  • parole assertive
  • écoute active
  • Le deuxième accord et le Pardon
  • exprimer sa colère, sa peur, sa tristesse
  • exprimer la joie
  • le corps pour couper court au bavardage incessant du parasite

  • Du Guetteur au Chevalier
  • ...

J'ai découvert la voie toltèque en 2000 et depuis, c'est la "colonne vertébrale" de mon chemin. Je partage ici différentes pratiques de la voie, enseignées par de nombreux "Transmetteurs" : Miguel Ruiz, Carlos Castaneda, Luis Ansa, Victor Sanchez...

 

Les ateliers ont lieu à l'Impératrice, Perpignan.  Ils se déroulent de 11 à 13 heures.


AtelierDate
1
06 oct.18
203 nov.18
301 déc.18
4
05 janvier 19

5à définir

 

Inscriptions, planning sur le site de l'Impératrice, Perpignan.


Conférence et ateliers "Accords Toltèques"

09/08/2018

Conférence et ateliers "Accords Toltèques"

Le livre « les quatre accords toltèques » de Miguel Ruiz est un best-seller.

La puissance et la simplicité de ces accords donnent envie de les mettre en pratique. Ils sont véritablement une ressource de transformation et de libération.

 

Cette conférence propose une vision originale et pragmatique des cinq accords ainsi qu’un protocole simple de mise en œuvre.

J'irai chercher des compléments, par exemple dans les neuro-sciences et le chamanisme pour présenter ma "compréhension" de ces accords et surtout les ingrédients nécessaires pour que cela fonctionne !

 

Livre "les quatre accords toltèques" sur youtube

 

Enfin, pour rappel, je suis un "franc-tireur" (combattant ne faisant oas partie d'une unité régulière).  Je ne sais pas si ma parole sera impeccable... Elle sera libre.

Ag'île : un jeu pour découvrir l'agile

17/05/2018

Ag'île : un jeu pour découvrir l'agile

 

  • une boussole
  • des vivres et de l'eau
  • des machettes
  • de quoi se protéger (un peu) des intempéries
  • un peu d'argile et d'huiles essentielles pour se soigner
  • ...

 

Pas de GPS, WIFI... Nous sommes quelque part au ... temps des Découvertes !

 

Le jeu "Ag'île"

Ce jeu permet de découvrir ce qu'est l'agile. Il met les joueurs en situation de s'auto-organiser.

Vous présentez la situation.

Question à poser : qu'allez-vous faire ? Comment vous organisez-vous ?

Après quelques minutes, précisez les questions (il s'agit d'une métaphore d'une approche agile, ne l'oublions pas !)

Quand utilisez-vous la boussole ?

Qui décide de ce qui est fait ? Comment les tâches sont-elles attribuées ?

Un débriefing le soir pour mieux préparer le lendemain serait il judicieux ?

Peut-être faudrait-il prévoir quand et comment abandonner ?

...

 

Après 10 ou 15 minutes, passez  au bilan du jeu.

 

Que représentait l'île ? le trésor ? la boussole ?

Faire un lien entre les propositions et les principes et pratiques agiles.

 

Enfin, la conclusion est une définition de l'agile en tant que discipline empirique pour répondre à une situation complexe, c'est à dire relativement imprévisible.

 

Illustration de Ag'île

 

 

Quelques pistes

Île : le développement d'un produit complexe, caractérisé par l'inconnu, l'imprévisible...

Trésor : la "valeur" (premier principe agile)

Boussole : un dispositif de feedback qui est une métaphore ("métaphore" est une pratique de l'Extreme Programming) :

  • Inspect et Adapt de Scrum et SAFe
  • Just in Time (et donc petit  stock) de Lean
  • Feedback concret et rapide de XP.

Notez que vous aurez probablement des propositions comme :

- la boussole c'est tout le temps

- au moins une fois par heure,

bref, la qualité du feedback réside dans ce qu'XP qualifie de concret et rapide.

Dans un cycle en V, la recette est un feedback concret mais beaucoup trop tardif !

 

Vous pouvez vous inspirer aussi de Carte, boussole et territoire sur la page Présentation de ce site.

C'est parti... Vous venez de débarquer :)