Autonomie
Les femmes et les hommes ne peuvent être liés par de fortes organisations et une autorité centrale.
Mon Coup de cœur, un petit bijou de Grand Corps Malade, ici ou ci-dessous :
…/…
Les femmes et les hommes ne peuvent être liés par de fortes organisations et une autorité centrale.
Mon Coup de cœur, un petit bijou de Grand Corps Malade, ici ou ci-dessous :
…/…
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 :
Tout d’abord afin de répondre à cette question, il nous faut définir de quel jardin il s’agit :
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.
Versions
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 ,:
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 :
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 :
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 :
Xx
…/…
Convivialité
Partage
Bienveillance
en un mot : authenticité
l’Essentiel :
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 :
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 :
…/…
Il nous faut avant toute chose :
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 :
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 :
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 :
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 :
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.
…/…
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.
Le Product management est un Program Lean-Agile Leader.
SAFe in a Nutshell
● 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
Le Product management est chargé de constituer le Program Backlog, de l’organiser, d’en assurer la priorisation.
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.
© Scaled Agile, Inc.
C’est donc bien le Product Management qui est propriétaire des Features Priorities.
© Scaled Agile, Inc.
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.
C’est le Product Management qui validera les Capabilities comme « Done ».
© Scaled Agile, Inc.
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.
© Scaled Agile, Inc
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.
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
© Scaled Agile, Inc.
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.
© Scaled Agile, Inc.
…/…
Dans les projets menés traditionnellement en cascade ou en cycle en V, le rôle du Project Manager était bien défini.
Que devient celui-ci dans les projets menés en mode Agile ?
Le « Traditional PM » participe dans les 5 groupes de processus de la façon suivante :
Dans les Projets menés en mode Agile, le rôle de Project Manager n’existe pas puisque nous souhaitons avoir des équipes Agile autogérées, autonomes.
Par contre, ce qui est nécessaire, c’est d’avoir des Lean-Agile Leaders qui permettront la transformation Agile et la montée en autonomie des équipes.
Voici comment ils peuvent intervenir :
Dans le framework Agile Scrum, le Lean-Agile Leader est le Scrum Master.
The Scrum Master is responsible for the following :
…/…
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.
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.
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 …).
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.
Cette démarche centrée sur une approche produit va faciliter aussi l’innovation et l’intelligence collective.
Les pré-requis pour un passage à l’échelle sont :
Les principaux modèles de passage à l’agilité à l’échelle sont :
Les méthodes Agile ou frameworks Agile nécessaires pour faciliter le passage à l’échelle ou Scaling Agile sont :
La démarche DevOps est au cœur de l’agilité à l’échelle, elle n’est surtout pas optionnelle.
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 sont des équipes qui travaillent de manière autonome.
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.
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é.
Cela sera organisé dans des séances de « Value Stream Analysis« .
Nous connaissions déjà les rôles de Product Owner, Dev Team, Scrum Master.
De nouveaux rôles pour le passage à l’agilité à l’échelle vont être nécessaires :
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.
© Scaled Agile, Inc..
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 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 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.
Les Business Owners ont une ou plusieurs des caractéristiques suivantes :
Pour plus d’informations sur les rôles, consulter l’article suivant : SAFe, roles in the Lean-Agile Enterprise
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.
© Scaled Agile, Inc..
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 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.
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.
La « continuous integration est décrite ici.
Le Programme est suivi en mode Kanban, ce qui permet de visualiser et manager l’ensemble du flux de valeur dans le Program Kanban.
Ceci permet de diminuer le Lead time.
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 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 ».
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.
Le cadencement et la synchronisation sont permis par l’approche de planification appelée « PI Planning » (Program Increment 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.
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.
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 ».
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 doit être réfléchie a minima au niveau programme.
La « System Team » va réfléchir sur l’Architectural Runway.
Le System Architect et la System Team préparent la conception émergente grâce aux Enablers.
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.
© Scaled Agile, Inc.null
La « SAFe Implementation Roadmap » va nous permettre de mettre en place une démarche et une transformation structurée.
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.
© Scaled Agile, Inc.null
x
../…
Ikigai ou « ma zone de bien-etre » combine 4 éléments essentiels de notre Vie :
Les 2 premiers éléments :
déterminent ma Passion.
Les 2 éléments :
me permettent de connaître ma Mission.
Les 2 éléments :
constituent ma Vocation.
Les 2 éléments :
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.
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.
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.
…/…
Références et sitologie :
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.
Non Solis
…/…
???????
Coach AGILE
Collectif Agile United
Bénéfices
Exploiter le potentiel
Former à la méthodo
favorise laCommunication
Element Moteur
Aide
Cohesion
Sous-sujet 7
Soft skills
Pedagogue
Role ponctuel
Bienveillance
Element Moteur
Guide
Accompagner
Acteur du Changement
Hard skills
Methodologie
Consignes/bonnes pratiques
Initie/Mène les cérémonies Agile
Ameliore les performances
Définie la stratégie
?
Collectif GOOD VYBES
Vision transverse du pilotage agile
Méthodes et valeurs
Gardien de la méthode
leadership légitimité conseil
Référent (externe)
Auditeur
CDC
Arbitre
Support aux eqpt
construction
stratégie de grp
formation acteurs
identifie l’humain
?
Collectif LAS
Ce qu’il est
Maitrise l’agilité
Expérience en Agilité
Orientation des équipes
Support
Accompagnement
Participe aux projets
Force de proposition
ce qu’il n’est pas
externe a l’equipe Agile
Presence pas obligatoire
externe au projet
?
Coach / Scrum ?
suivre …