Ceci bien sur est un clin d’œil au Candide de VOLTAIRE.
Au dernier chapitre du roman ou conte philosophique Candide, son personnage Candide qui échange dans une conversation triangulaire avec son précepteur et Maître Pangloss mais aussi avec Martin, un philosophe nous dit ceci :
il faut cultiver notre jardin
et par 2 fois, il répète cette métaphore
Quelle peut bien être la portée symbolique de cette métaphore pour l’écrivain VOLTAIRE et pour nous-même lecteur ?
Tout d’abord afin de répondre à cette question, il nous faut définir de quel jardin il s’agit :
est-ce notre jardin au sens matériel et physique du terme, c’est-à-dire, carré de légumes, potager et fruitier comme nous disons : allons-nous promener dans notre jardin ?
est-ce notre jardin au sens terrestre du terme, c’est-à-dire la Terre elle-même ?
ou au contraire, est-ce notre jardin intérieur, profondément enfoui au fond de nous et unique, définissant notre nature profonde ?
ou peut-être encore d’autres sens à découvrir à cette métaphore
Le meilleur des Mondes, tel que présenté par Pangloss dans ce dernier chapitre, l’Eden n’existe pas.
Il nous faut donc nous contenter de cultiver notre Jardin intérieur, agir ce sur quoi nous pouvons agir et se contenter d’accepter les éléments de la Vie que nous ne pouvons pas changer.
Nous sommes dans un processus de développement personnel depuis que nous sommes venus au monde.
Nous sommes engagés consciemment ou non dans une transformation permanente, un maelström, …
Voir la double hélice de la dynamisation décrite par les Biodynamistes.
Connais-toi toi-même ou le « Gnothi seauton » de SOCRATE était, en réalité, un des 3 préceptes inscrit au fronton du Temple de Delphes.
Les Romains l’ont transcrit en « Nosec te ipsum ».
Voir origines de l’agriculture (cemagref 1982)
Homo faber
Puis Homo sapiens
Et ensuite Homo sapiens sapiens
Gnothi seauton
Donc nécessité d’apprendre à « Apprendre »
Ce qui nécessite les valeurs suivantes ,:
Humilité
Tempérance
Bienveillance
Empathie
Authenticité
Pragmatisme
Simplexité
Voir Carl JUNG : Essai d’exploration de l’inconscient
Un maître soufi expliquait à ses disciples que pour trouver de l’eau dans le désert, la méthode la plus efficace était de creuser de plus en plus profond toujours au même endroit.
Les résultats sont toujours statistiquement plus grands et de loin que forer de manière aléatoire une multitude de trous superficiels.
Et pourtant plus de 80% des humains utilisent la 2eme approche.
La première approche est une approche Agile.
Avec empirisme, par inspection et adaptation, dans la plus grande transparence nous allons modifier notre processus et notre démarche.
Mieux se connaître nous permet de nous trouver davantage dans notre zone de bien-être :
Par rapport à nous-mêmes, ce qui est essentiel
Et vis-à-vis des autres, ce qui est important
Se connaître soi-même se développer, se transformer, c’est actualiser ses potentialités.
C’est faire grandir ce qui est déjà en nous depuis notre naissance.
En un mot, c’est exploiter son Talent.
Parabole :
Et Toi, qu’as-tu fait de ton Talent ?
Voir extrait « Crabe tambour » de Schöendorfer
Se connaître soi-même, ce n’est que devenir ce que nous sommes.
C’est simple et terriblement complexe à la fois.
Et en plus, cela se passe sur une approche humaine en univers complexe et changeant.
Depuis notre naissance, nous ne faisons que changer, nous transformer, consciemment ou inconsciemment.
Mais c’est mieux de le faire consciemnent.
Cest la démarche de développement personnel.
Parmi les multiples chemins de développement personnel, il nous appartient de trouver celui qui nous convient le mieux.
Et n’oublions pas, comme les pèlerins de Compostelle, l’essentiel, c’est d’être en chemin.
Outcomes are better than thanks outputs.
l’Essentiel est de creuser son sillon, le plus profondément possible.
Rappelons-nous la fable de Mr de la Fontaine, le Laboureur et ses enfants :
Creusez, creusez, …. C’est le fond qui manque le moins !
Xx
…/…
Convivialité
Partage
Bienveillance
en un mot : authenticité
l’Essentiel :
Énergie
Fluidité
Dynamisme
Ce que nous pourrions peut-être résumer par le terme de Convivialité
Les valeurs du Rugby
Convivialité et Partage
…/. ..
Microcosme et Macrocosme
L’Honme, la personne humaine est un univers en réduction.
Image du Nautilus
Notre seul but (Goal) dans la Vie est :
Exploiter notre Talent
Développer nos potentialités
de faire preuve de réalisme et de pragmatisme
Que ce soi vis-à-vis de nous-mêmes ou vis-à-vis des Autres.
Dans une démarche pratico-pratique simple et essentielle, la démarche méthodologique ne peut être éloignée de la suivante :
De solides fondations, valeurs et principes
Un modèle humaniste
Un outil de développement personnel, l’enneagrammne
Des travaux de recherche personnelle
Des compétences, des connaissances et des aptitudes particulières
Et enfin une personnalité unique, un caractère et un leadership unique
Et pour alimenter tout cela beaucoup de créativité
…/…
Il nous faut avant toute chose :
Connaître nos préférences
Choisir son Chemin
Trouver son énergie et son bien-être
Mettre en place sa dynamique
Découvrir un Sens à sa Vie
Faire de sa passion son Métier
Continuer à apprendre à apprendre tout au long de sa Vie
Finalement ce blog n’a qu’une volonté, partager avec vous 52 ans de recherches et de développement personnel.
La réflexion commence en 1967, suite à un accident.
Ce n’est que le premier d’une longue liste.
Été 1967, salle de bal, 14 juillet :
Bras cassé, en réalité, radius + cubitus
Première anesthésie générale
…
Avant il y avait déjà eu , en 1966 (?), Coup de couteau.
Première cicatrice.
Mais pas la dernière.
Je m’aperçois maintenant avec. Plus de cinquante ans de recul, que je n’ai jamais mis mon corps à l’économie.
Ma grande interrogation et peut-être aussi mon angoisse, « suis-je vivant ? ».
Voir portrait d’un coaché par la Process com.
Comment rendre cette base « Rebelle », et cette phase « empathique » acceptable, employable, etc.
Et nous en arrivons sur le 3ème niveau, « suis-je aimable » du côté Empathique.
Les autres côtés, Persévérant, Rêveur, Travaillomane, ne viendrons qu’ensuite en fonction des situations, des contextes, des enjeux et surtout des challenges humains.
MBTI :
ENFP
. …/. …
Modèle de Ned Hermann, les 4 quadrants
Modèle de BELBIN.
Autres modèles et dynamiques de personnalité.
…/…
Mais en l’état de notre propos, une réflexion s’impose :
Comment mieux se connaître !
Et surtout derrière tout cela comment garder sa jeunesse d’esprit et sa curiosité vis-à-vis de ce que la Vie nous propose, ses joies et ses épreuves.
Et tout cela avec beaucoup de créativité dans une démarche ludique d’auto-apprentissage, en un mot, une démarche Lean-Agile.
ENFP :
Goût de l’anticipation
Intuitions pénétrantes
Grande créativité
Sensibilité artistique, recherche du Grand Œuvre
Les ENFP sont excellents dans les relations humaines ils sont bienveillants empathiques, chaleureux, spontanés, simples et pragmatique, authentiques
Curiositė insatiable, goût du challenge, volonté de comprendre la face cachée des choses.
Mais aussi leur spontanéité les amène souvent à être très maladroit dans leur comportement et leurs paroles.
Ce qui bien sûr était à l’opposé de leur intention profonde.
Xx
ENFP, type 7 de l’enneagrammne et bipolarité !
A creuser et à suivre …. Avant toute chose il faut s’appuyer sur un cadre fort de valeurs et principes, dans une approche éthique et déontologique élémentaire et essentielle.
Cela peut sembler peut-être désuet, trop simple pour être vrai, mais c’est pour moi la seule approche possible.
Je suis né dans les années 50, au cœur du Poitou, en milieu rural et artisan.
Culture du partage, de la convivialité, du Savoir-faire.
Citation de Jean GIONO, Extrait des Vraies Richesses.
Que devient le Program Manager dans l’agilité à l’échelle (Scaling Agile) ?
Dans l’approche classique des Projets, le Program Manager coordonnait l’ensemble des Projets constituant le Programme de Projets.
Il était chargé de fixer le But (Goal) du Programme et de fédérer les différents Project Managers responsable de chaque Projet.
Dans l’approche Agilité à l’échelle (Scaling Agile), ce rôle de Program manager n’existe pas. Le Program Manager est remplacé par le rôle de Product Management.
Product management as a Lean-Agile Leader in Scaling Agile
Le Product management est un Program Lean-Agile Leader. ● He charts the future by anticipating and preventing issues that are potential impediments for the Team. ● The role is key for leading organizational change management activities that enable cross-functional Teams to adapt to the changes in the working environment. ● Schéma p 40
SAFe in a Nutshell
Le Product management est chargé de constituer le Program Backlog, de l’organiser, d’en assurer la priorisation.
Product management et Program Backlog
Product Management has content authority for the Program Backlog. They are responsible for identifying Customer needs, prioritizing Features, guiding the work through the Program Kanban and developing the program Vision and Roadmap.
C’est donc bien le Product Management qui est propriétaire des Features Priorities.
A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).
Le Product Management va travailler avec les différents Product Owners de chacune des Equipes pour planifier la Release.
Product management et Release
C’est le Product Management qui validera les Capabilities comme « Done ».
A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in a single PI.
Ce Product Management s’assurera après chaque Program Increment (PI) qu’une partie importante du Produit a bien été mise en Release à la Production.
Features also lend themselves to the Lean UX process model, which includes a definition of the Minimum Marketable Feature (MMF), a benefit hypothesis, and acceptance criteria. The MMF helps limit the scope and investment, enhances agility, and provides fast feedback. Capabilities behave the same way as features. However, they are at a higher level of abstraction and support the definition and development of large Solutions.
La System Demo est conduite par le Product management les POs et la System Team.
Product Management, Program Backlog, Continuous exploration, Features et Capabilities
Features in context of SAFe
Le Product Management collabore avec les Customers, les Key Users, les Stakeholders, les Business Owners, Les System Arch/Eng, les RTEs, les Teams pour assurer la Continuous Exploration.
The primary responsibilities of Product Management in the context of a single Agile Release Train (ART) are :
– Understand customer needs and validate solutions
– Understand and support portfolio work
– Develop and communicate the program vision and roadmap
– Manage and prioritize the flow of work
– Participate in PI planning
– Product Management works with release management
– Participate in demos and Inspect and Adapt (I&A)
– Build an effective Product Management/Product Owner team
Product Management is the internal voice of Customer
En résumé, nous pouvons dire que le Product management est la voix interne du Customer ou des familles de Clients.
Product Management – is the internal voice of the Customer and works with Customers and Product Owners to understand and communicate their needs, define system features, and participate in validation. They are responsible for the Program Backlog.
L’agilité à l’échelle, ou «Agile@Scale» ou parfois « Scaling Agile », consiste à mettre en place un cadre pour faire travailler plusieurs équipes ensemble et en parallèle, ces équipes travaillant bien sûr elles-mêmes en mode Agile.
La vision du Scaling Agile
Pour mettre en place cette approche, il faudra créer une organisation qui permettra de faire travailler de manière transverse toutes ces équipes ensemble autour d’un même produit (ou de plusieurs produits), que ce soit pour de la création d’un produit ou d’une modification de version.
Mettre en place l’agilité à l’échelle incluera également la transformation profonde et globale de l’entreprise (management, budget, ressources humaines, métiers, commerce, marketing, chaîne logistique d’approvisionnements et de livraisons, partenariats, contrats, … ).
Ce sont le coaching, le mentorat et la formation qui permettront aux collaborateurs de s’intégrer dans cette transformation.
Ceci implique un changement de paradigme, et il est difficile de transformer réellement l’entreprise si l’ensemble de l’entreprise (en particulier le Management) n’adhère pas à cette vision systémique.
Pour cela, il existe plusieurs modèles ou frameworks (cadres de travail) différents qui permettent de faire de l’agilité à l’échelle.
Ceux-ci sont en général assez différents et répondent à des problématiques et des enjeux distincts.
Certains frameworks d’agilité à l’échelle sont aussi liés à des philosophies qui diffèrent par leur approche du coaching Agile.
Sur quoi agit le Scaling Agile
Lorsqu’une Organisation souhaite passer à l’agilité à l’échelle, c’est-à-dire introduire l’agilité à tous les niveaux de l’entreprise, il faut un changement d’approche par rapport aux projets menés traditionnellement en « cycle en cascade » ou « cycle en V ».
Et plutôt que continuer à travailler dans une Organisation en silos, il faudra introduire de la transversalité et de l’approche globale ou systémique centrée sur le Client.
Mais avant de passer à l’agilité à l’échelle, il faudra commencer par maîtriser les méthodologies Agile de base (Scrum, Lean, Kanban, Crystal clear, ASD, FDD, DSDM, XP …).
Agile methodologies
Dans quel but passer au Scaling Agile ?
Le Scaling Agile permet de mieux s’adapter et se réadapter à un marché qui évolue de plus en plus vite dans des univers complexes et changeants.
Cela va permettre aussi de raccourcir le « Time to Market » en diminuant le « Lead Time », notion essentielle pour se démarquer de ses concurrents.
La démarche DevOps est au cœur de l’agilité à l’échelle, elle n’est surtout pas optionnelle.
Disciplined DevOps
La démarche DevOps est une base de travail intéressante au service de valeurs Agile ou d’une philosophie Agile adaptée à l’ensemble de l’Organisation et à tout son écosystème de Partenaires.
Il faut être conscient qu’aucune approche d’agilité à l’échelle n’est la solution unique à toutes les problématiques.
Il faut réfléchir en fonction de l’environnement, du contexte, de l’écosystème de partenaires et des enjeux et voir quel va être le modèle le plus approprié.
Le modèle SAFe se démarque par son approche structurée « Entreprise » et son succès commercial.
Les Feature Teams
Les Feature Teams sont des équipes qui travaillent de manière autonome.
Cross functionnal Team
Une « Feature Team » est une équipe qui développe, teste, déploie et idéalement livre ses « Features ».
Une Feature Team est une équipe Agile multi-disciplinaire, cross-fonctionnelle, auto-Organisée, autogérée (voir Agile Teams).
C’est une notion indispensable pour le passage à l’agilité à l’échelle.
Le Scrum Master sera là pour aider les équipes à être autonomes.Elles sont autogérées.
Il pourra être formé et supervisé par le Coach Agile.
Au niveau du management, cette autonomie des équipes est un changement d’approche essentiel et il sera important que le coach Agile accompagne les Managers sur cet aspect, de façon à ce qu’ils puissent favoriser la montée en compétences et en connaissances de leurs équipes.
Le System thinking
L’approche Produit ou System thinking est centrale, c’est elle qui va permettre la coordination, la synchronisation et le cadencement.
Ce qui est essentiel, c’est de réfléchir avec toutes les Parties Prenantes à optimiser la performance du Value Stream plutôt que sur-optimiser une partie de l’activité.
De nouveaux rôles pour le passage à l’agilité à l’échelle vont être nécessaires :
Product Management (owns, defines, prioritize the Program Backlog)
System Architect / Engineer (System Arch/Eng) provides : architectural guidance, technical enablement to the Teams on the Train
Release Train Engineer (RTE) = Chief Scrum Master for the Train
Business Owner(s) = Key Stakeholders on the Lean Agile Release Train (ART)
Le rôle de Product Management
Le rôle de Product Management est un rôle essentiel pour le management de programme Agile.
Il est d’autant plus important que nous quittons une démarche Projet pour aborder une démarche Produit, le Lean Product Management sans perdre de vue notre démarche d’excellence et de qualité totale.
Le Product management est le leader sur le Contenu à délivrer (Content Authority).
Il est une sorte de Product Owner Leader.
Product Management has content authority for the Program Backlog. They are responsible for identifying Customer needs, prioritizing Features, guiding the work through the Program Kanban and developing the program Vision and Roadmap.
Il s’appuie notamment sur les Product Owner des Scrums Teams (et/ou Business Analyst,… des autres Teams) dans l’idée d’en faire une équipe collaborative centrée sur la création du Program Baclog et sa gestion.
Cette équipe doit être focalisée sur la production de valeur pour le Client (et par là même la création de valeurs pour les Utilisateurs).
Le rôle de System Architect / Engineer
Le System Architect / Engineer (System Arch/Eng) est le leader de la solution Technique à délivrer (Design Authority).
Il s’appuie notamment sur les Développeurs des Scrum Teams (et/ou Architectes, Développeurs,des autres Teams) et la System Team.
Le rôle de Release Train Engineer (RTE)
Le Release Train Engineer (RTE) est le leader sur le Processus et son exécution.
Il s’appuie sur les Scrum Master des Scrum Teams (et/ou Chefs de Projet (CP) des autres Teams).
C’est aussi une sorte de coach pour l’ensemble des équipes qui constituent le Train.
Il est une sorte de super Scrum Master, un Scrum Master Leader.
Le rôle de Business Owner
Les Business Owners ont une ou plusieurs des caractéristiques suivantes :
ils ont autorité pour engager les moyens humains et financiers demandés par la phase Design et/ou Delivery
ils sont partie prenantes (clients ou impactés) par le Produit/Service à concevoir (Business, Métier (processus, positions de travail, …)
ils s’inscrivent dans un temps long, celui du cycle de vie du Produit/Service, donc au-delà du Projet
Puisqu’il y a plusieurs équipes qui travaillent en parallèle, pour faciliter le cadencement et la synchronisation à coordonner, il va donc nous falloir une équipe centrée sur les aspects coordination, c’est la System Team.
The System Team is a specialized Agile Team that assists in building and supporting the Agile development environment, typically including development and maintenance of the toolchain that supports the Continuous Delivery Pipeline. The System Team may also support the integration of assets from Agile teams, perform end-to-end Solution testing where necessary, and assists with deployment and Release on Demand.
La System Team fournit les process, outils et support pour intégrer et évaluer le System très tôt dans le cycle de Delivery et le plus souvent possible.
Le périmètre du Programme : le Backlog Program
Le périmètre du produit est représenté par un artéfact appelé Program Backlog.
En effet, il n’y a qu’un seul Program Backlog en relation avec le Product Backlog de chaque Dev Team.
C’est la coordination de ces différents Product Backlogs et la synchronisation et le cadencement qui font l’agilité à l’échelle.
Continuous exploration, Continuous developement, Continuous deployment, Release on Demand
La centration continue sur le Produit permet la « Continuous exploration », le « Continuous developement », le « Continuous deployment » et la « Release on Demand » créatrice de valeurs business pour le Client.
C’est la fin du « start & stop » du mode Projet, remplacé par l’approche Produit.
Ceci constitue un changement de vision essentiel pour le passage à l’agilité à l’échelle avec un autre regard sur les coûts (voir Lean budgeting).
La priorisation du Program Backlog
La priorisation du Program Backlog se fait par la méthode MoSCoW.
C’est une priorisation par le coût du retard, « Cost Of Delay (CoD) » et la durée.
Si la durée n’est pas facile à estimer, elle peut être remplacée par l’effort de réalisation plus facile à estimer en relatif.
C’est la notion de « Job size ».
Cadencement et synchronisation
Ce sont le cadencement et la synchronisation qui permettent la coordination et la livraison de valeurs.
Le cadencement sans la synchronisation n’est pas suffisant.
La Synchronisation permet d’assurer le Delivery
Comme nous sommes dans une approche Lean, le principe sous-jacent à la synchronisation est d’augmenter la fréquence des boucles d’apprentissage (les feedbacks).
Le principe sous-jacent à la synchronisation et au cadencement est d’augmenter la fréquence des boucles d’apprentissage.
Boucle d’apprentissage
Le cadencement et la synchronisation sont permis par l’approche de planification appelée « PI Planning » (Program Increment Planning).
Le PI Planning
PI Planning
Le PI Planning est une cérémonie de planification du Program Increment, l’artéfact qui sera créé à la fin de chaque itérations menées en parallèle par les différentes équipes constituant le Train.
Ce PI Planning va donner la cadence du Train.
Cette cérémonie dure 2 jours toutes les 8 à 12 Semaines (10 en moyenne).
Le Train est constitué de 50 à 125 personnes, c’est le nombre de Dumbar, nombre idéal pour lancer une transformation.
Tout les Acteurs y assistent.
Le Product Management priorise les Features.
La Dev Team ou équipe de réalisation planifie les différentes Stories et fait une première estimation de ces Stories.
Le travail des différentes équipes est planifié sans oublier bien sûr les dépendances entre équipes.
Ces dépendances seront prises en charge par la System team.
Approche Lean Start-up
Comme nous sommes dans une approche Lean centrée sur la création de Valeurs, il est privilégié une approche de type Lean Startup.
Cette approche de type Lean Startup permet des cycles courts, avec des itérations de 2 semaines (Lean Start-up Cycle).
Ces itérations de 2 semaines menées en parallèle par les différentes équipes constituant le Train vont faciliter le cadencement et la synchronisation.
Réaliser un Program Increment avec SAFe
La réalisation d’un Program Increment avec SAFe se fait avec plusieurs itérations menées en parallèle.
Ce sont le cadencement et la synchronisation qui permettent de créer cet artéfact : le « Program Increment ».
SAFe Roadmap
La Roadmap est un engagement et une prévision adaptable de System Demo ( big Review) en System Demo.
Et bien sûr, en parallèle le contact est maintenu tout le long du cycle avec les utilisateurs et en particulier les « Key Users » ou « Personas »; ce qui va permettre de récupérer de l’information et des feedbacks, c’est le « Lean UX Cycle »,.
Ce lean UX Cycle va permettre l’adaptation et la réadaptation
La modélisation
La modélisation doit être réfléchie a minima au niveau programme.
La « System Team » va réfléchir sur l’Architectural Runway.
Architectural Runway
Le System Architect et la System Team préparent la conception émergente grâce aux Enablers.
Intentional Architecture and Emergent Design
Enablers support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development. They are captured in the various backlogs and occur at all levels of the Framework.
La « SAFe Implementation Roadmap » va nous permettre de mettre en place une démarche et une transformation structurée.
SAFe Implementation Roadmap
The SAFe Implementation Roadmap consists of an overview graphic and a 12-article series that describes a strategy and an ordered set of activities that have proven to be effective in successfully implementing SAFe. Achieving the business benefits of Lean-Agile development at scale is not a trivial effort, so SAFe is not a trivial framework. Before realizing SAFe’s rewards, organizations must embrace a Lean-Agile Mindset as well as understand and apply Lean-Agile principles. They must identify Value Streams and Agile Release Trains (ARTs), implement a Lean-Agile portfolio, build quality in, and establish the mechanisms for continuous value delivery and DevOps. And, of course, the culture must evolve as well. Based on proven organizational change management strategies, the SAFe Implementation Roadmap graphic and article series describes the steps, or ‘critical moves,’ an enterprise can take to implement SAFe in an orderly, reliable, and successful fashion.
Ikigai ou « ma zone de bien-etre » combine 4 éléments essentiels de notre Vie :
ce que j’aime
ce en quoi je suis bon
ce dont le monde a besoin
ce pour quoi je puis être payé
Ikigai (ma zone de bien-être)
Les 2 premiers éléments :
ce que j’aime
ce en quoi je suis bon
déterminent ma Passion.
Les 2 éléments :
ce que j’aime
ce dont le monde a besoin
me permettent de connaître ma Mission.
Les 2 éléments :
ce en quoi je suis bon
ce dont le monde a besoin
constituent ma Vocation.
Les 2 éléments :
ce dont le monde a besoin
ce pour quoi je puis être payé
sont mon Métier.
La zone de bien-être ou Ikigai permet de combiner Passion, vocation, métier et mission.
Nous pouvons donc fonctionner à notre plus haut niveau d’énergie et bénéficier de tout notre potentiel créatif.
Ikigai et notion d’équilibre
L’ikigaï est une question d’équilibre.
Si une composante est privilégiée par rapport aux autres, alors il n’y a pas équilibre, et donc il n’y a pas ikigaï et par conséquent plus de bien-être.
L’ikigaï est donc un concept particulièrement intéressant pour qui recherche un meilleur équilibre vie professionnelle/vie personnelle, et davantage de sens dans son travail.
Ikigai et burn-out
L’ikigai et le burn-out sont focéments liés.
Ne plus fonctionner dans sa zone de bien-être sous-entend être plutôt en mal être.
Plus ce mal être est important, plus nous allons consommer de l’énergie pour essayer de retrouver notre équilibre, notre homéostasie.
Notre sécurité ontologique se trouve donc menacée d’où stress négatif important.
Et si le stress est important et continu, il peut conduire au burn-out.
Nous ne pouvons parler de coaching Agile sans parler du principe de la dynamisation.
Avant de donner vie au collectif Agile, il faut d’abord dynamiser ou re-dynamiser chaque élément de ce collectif.
L’action de dynamisation se joue bien sûr entre le coaché et le coach certes, mais aussi et surtout, bien que cela soit souvent négligé, entre le coaché et lui-même.
Il va s’agir pour le coaché de revisiter sa vision du monde de l’Entreprise, revoir sa conception archaïque d’une entreprise (Eden primitif d’avant Internet) et la représentation qu’il s’en fait.
A ce totem, il va falloir tailler les tabous, débusquer et éclairer les non-dits pour reconstruire un nouveau paradigme, brique par brique.
Ces briques vont devenir le socle et le temple de sa nouvelle réalité retrouvée.
Pour cela, il lui faudra faire appel à toutes ses capacités intellectuelles, mentales, physiques, énergétiques et autres ainsi qu’à l’utilisation de tous ses sens.
C’est ainsi qu’il pourra de lui-même apprendre à simplifier, optimiser, automatiser, être créatif et trouver la solution qui lui conviendra le mieux.
Le coach travaillera aussi sur l’axe collectif, rapport du coaché avec le collectif dont il appartient.
Le travail sur ces 2 axes et le principe de dynamisation permettront la montée en autonomie, à la fois personnelle et collective.
