Le télétravail est devenu une norme dans le service informatique depuis la pandémie de covid. Avant les différents confinements on en voyait les prémices mais les managers étaient très réticents à l’idée de laisser leurs collaborateurs rester chez eux. Dans mon entreprise de services de l’époque, la possibilité nous était offerte (2 jours par mois maximum) mais il fallait prévenir à l’avance, avoir une raison et rendre compte de son activité de la journée. On était loin des valeurs de confiance et d’autonomie du manifeste Agile.

Avec l’arrivée du confinement les entreprises y ont subitement trouvé un intérêt, et les limites techniques (connexion VPN ou autres) ont disparu aussi vite que les rouleaux de PQ dans les rayons des supermarchés. Cette occasion forcée de faire fonctionner des projets à distance a permis de prouver son efficacité et de balayer les idées reçues du télétravailleur qui se la coule douce.

L’agilité dans tout ça ? J’étais présent aux Agi’Lille il y a 3 000 ans quand ça s’appelait encore Agile Tour. Avant la pandémie on insistait énormément sur la colocalisation des équipes pour un produit réussi…

Télétravail et Agilité n’ont donc pas toujours été une évidence. Comment faire fonctionner au mieux une équipe produit Agile partiellement à distance ? Je vais tenter d’apporter des éléments de réponse liés à mon vécu, un retour d’expérience de ma courte carrière qui au mieux vous fournira quelques tips pour travailler avec votre équipe et au pire vous divertira (engagement non contractuel).

Mon contexte (en 1 mot c’est important)

J’ai commencé dans l’IT en tant que dev java au sein d’une équipe soudée et colocalisée avec de bonnes valeurs Agile, j’ai eu cette chance de voir une équipe fonctionner correctement et s’entraider pour atteindre un but commun malgré tous les aléas projets qui arrivent. Je suis passé par 2 grosses ESN avant d’arriver chez EKITE ; j’ai pu voir beaucoup d’autres contextes projets moins stimulants et enrichissants. Je me suis éloigné du développement pur et dur pour basculer sur un rôle plus fonctionnel après quelques années.

Je garde à ce jour un léger regret de m’être éloigné du développement, mon esprit logique y trouvait une grande satisfaction. Les contextes projets où le rôle de développeur est dépouillé des aspects de conception et réduit à simple exécutant m’ont poussé à vouloir changer de rôle.

Je voulais faire le lien entre les métiers et l’équipe de développement, le tout dans un contexte Agile qui correspondait à mes convictions (auto-organisation, amélioration continue, responsabilité, confiance). Je suis donc devenu… chef de projet MOE sur un projet cycle en V codé en COBOL de plus de 100 personnes dans le secteur bancaire ! Assez éloigné de mon envie première, j’ai tout de même trouvé de l’intérêt dans la mission. Je reste convaincu qu’on a à apprendre de chaque situation et que c’est la richesse du rôle de consultant de découvrir et s’adapter à chaque contexte.

C’est pendant cette mission que le premier confinement survint pour moi. Le full remote imposé n’est pas pour moi ; c’est une certitude, j’ai besoin de voir les collègues et de créer du lien. Je cogite beaucoup sur ma situation personnelle et professionnelle. Déconfiné et motivé j’avais alors 2 objectifs clairs :

• partir habiter sur la côte d’Opale avec ma conjointe ;
• devenir Product Owner et quitter mon ESN actuelle.

Le télétravail étant maintenant entré dans les mœurs, ces 2 objectifs ne sont désormais plus incompatibles et c’est une chance inouïe. Dans mon enfance j’ai déménagé 3 fois avec ma famille pour suivre les changements de travail de mon papa dans l’industrie. Dans nos métiers et à notre époque on peut à présent choisir son lieu de vie en faisant entrer d’autres critères que la proximité du bureau.

J’ai rejoint la dream team d’EKITE et décroché ma première mission de PO peu de temps après. Côté perso on a ciblé Wimereux pour s’établir, notamment pour sa proximité avec la gare de Calais Fréthun (à 30 minutes de Lille Europe en TER GV).

Les Tips

Disclaimer : je n’ai jamais fait de full remote (volontaire), les tips prodigués ici seront donc plus adaptés à du télétravail partiel.

Une bonne communication
Communiquer correctement est très important en télétravail pour éviter les pertes d’informations et la sensation d’isolement. Ça passe en premier lieu par le choix d’un outil bien adapté (type Slack). Il faut ensuite configurer correctement cet outil. Bien organiser les différents canaux permettra de s’y retrouver facilement pour tout le monde.
Un effort doit être fait pour formaliser un maximum les communications. Je demande à l’équipe d’éviter un maximum les messages privés et de poser les questions (entre eux ou à moi) sur les canaux destinés à l’équipe. Un fil de discussion se crée alors autour du sujet et les autres membres de l’équipe peuvent participer ou consulter. Cela recrée un peu ce qui se passe naturellement en open space où on gagne en connaissance globale du projet en laissant traîner une oreille.
Il faut également savoir choisir son moyen de communication en fonction du besoin. La messagerie est adaptée à une communication rapide et asynchrone mais ne doit pas remplacer les meets quand nécessaires pour avancer rapidement sur un sujet (avec mon équipe on a pour habitude de se retrouver sur le meet du daily meeting à toute heure de la journée quand besoin de travailler à 2 ou 3). De même en fonction de l’enjeu et des interlocuteurs un e-mail restera parfois préférable pour attendre une réponse plus complète et formelle.

Des outils adaptés à la collaboration
Les outils utilisés par l’équipe doivent être adaptés à la collaboration. La création d’un board virtuel pour suivre l’avancement de l’équipe semble essentielle. Jira, Trello ou autre, ça dépendra de l’organisation de l’entreprise en question. Quel que soit l’outil il faudra prendre le temps de le configurer correctement pour le rendre clair et adapté au contexte de l’équipe. Garder uniquement les colonnes nécessaires et pertinentes au flux de travail de l’équipe facilitera la prise en main intuitive. De même j’aime supprimer les contraintes qui peuvent exister entre les différents statuts pour simplifier la gestion (là encore à adapter).

Un panel de rituels pertinents
Les rituels mis en place doivent être adaptés à l’équipe et avoir un intérêt. C’est un peu la base de l’Agilité, il faut les adapter au fil du temps pour les faire correspondre aux besoins de l’équipe. En faisant participer l’équipe à leur amélioration on s’assure que tout le monde vient avec un objectif précis en tête et sans traîner les pieds. La co-construction et l’autonomie de l’équipe s’en trouveront renforcées. Pour éviter une posture trop passive aux daily meetings j’ai mis en place un picker sur Slack qui sélectionne aléatoirement chaque matin un membre de l’équipe pour l’animation. Ce simple rôle tournant a permis dans mon équipe une meilleure appropriation du board et une meilleure écoute. Demander à activer les caméras, si ça ne dérange pas les gens, aide aussi grandement à impliquer les autres et permet d’avoir un feedback visuel très important pour une bonne communication.

Synchroniser les jours sur site
Même si ça semble être du bon sens il est important que les jours en présentiel soient communs à toute l’équipe. Sans ça, venir sur site ne va vraiment rien apporter. Les jours sur site sont parfois moins productifs qu’en télétravail mais il ne faut pas négliger l’aspect social. C’est le moment où on peut prendre un café ensemble, faire un petit resto le midi, etc. Mieux se connaître facilite grandement le travail à distance derrière. Quand on a appris à se connaître on est plus à l’aise pour interagir et poser des questions via chat. On gagne en bien-être et en efficacité dans le travail en équipe.

Organiser les jours en télétravail vs les jours en présentiel
Comme évoqué juste avant, il faut laisser du temps à la convivialité les jours en présentiel. Pour ce qui est du travail on peut être tenté de condenser les rituels et ateliers sur ces jours colocalisés. En effet les ateliers se font plus simplement tous ensemble autour d’un tableau mais il faut veiller à laisser du temps. L’intérêt pour l’équipe est aussi de pouvoir travailler ensemble, s’entraider, valider les PR, etc. Encore une fois, transformer ces jours sur site en grande réunion risque de rebuter l’équipe qui viendra à contre-cœur et laissera peu de temps pour craquer des sujets techniques. Les ateliers peuvent également bien se conduire à distance avec les bons outils. Au-delà du très connu Miro, je vous invite à jeter un œil à Metro Retro (boards collaboratifs pour retrospective, story mapping, vision board, etc.) et Pointing Poker (outil pour scorer les tâches à distance facilement).

Les pistes

Full remote
Comme évoqué le full remote est encore différent, des collègues l’ayant pratiqué m’ont expliqué que la création de lien se faisait toujours via des événements ensemble en présentiel. Il faut l’outillage adapté et des personnalités compatibles. À la suite des confinements, de nombreuses personnes ont mal vécu l’isolement. Même s’il est possible de socialiser autrement qu’au travail, ça reste important pour de nombreuses personnes, je pense que chacun le vit différemment.
Un outil intéressant pour recréer une ambiance bureau à distance est Work Adventure. J’ai découvert cet outil lors de l’Agi’Lille qui s’est déroulé pendant le covid. Dans Work Adventure chacun se crée son personnage et se déplace comme dans un jeu en 2D sur une carte (qui peut être personnalisable pour recréer ses bureaux en open space). Un outil de visio y est intégré très intelligemment. Quand on s’approche de quelqu’un disponible, une conversation téléphonique est ouverte. Quand on rentre dans une salle de réunion, un meet avec partage d’écran est ouvert.

Onboarding et équipe hybride
L’onboarding à distance est également un point d’attention. Idéalement tout doit être documenté pour pouvoir intégrer une nouvelle personne facilement. Quelques jours sur site sont aussi préférables pour aider à l’intégration.
Quand une personne est en full remote alors que les autres membres de l’équipe sont en télétravail partiel (équipe hybride) il faut aussi faire attention. La communication doit être aussi rigoureuse les jours sur place que les jours en télétravail pour n’exclure personne. Nous avions tenté également un rituel café à distance pour créer des moments d’échanges et de cohésion.

Un bilan positif

Télétravail et Agilité sont-ils compatibles ? Un grand oui et heureusement ! Les équipes ne sont plus colocalisées 100 % du temps mais avec les bons outils et la confiance du management (très importante) une équipe suffisamment mature peut très bien s’organiser en télétravail, voire mieux que sans. Les valeurs de confiance, d’autonomie et de transparence, mises en avant dans l’Agilité, sont également des clés de succès pour un travail à distance réussi. Ne pas être en open space 5j/5 est aussi un plus ; de nombreuses études ont montré que ce cadre de travail se fait vieillissant et que les échanges écrits ont augmenté avec la disparition des cloisons (un comble). Le télétravail partiel est pour moi le meilleur des deux mondes.

Tout le monde y gagne :

• l’entreprise réduit ses frais immobiliers en réduisant le nombre de bureaux ;
• le collaborateur gagne en flexibilité et améliore son équilibre vie pro/vie perso ;
• la planète se porte mieux en diminuant les émissions de CO2 liées aux trajets domicile/travail.

Sources

Le télé-travail, anti-agile ? Bilan

https://thedaily.swile.co/open-space

https://hbr.org/2019/11/the-truth-about-open-offices

L’article Le télétravail Agile est apparu en premier sur EKITE.

Les différentes cibles que nous retrouverons la plupart du temps sont les suivantes :

• Utilisateurs
• Equipe
• Sponsor
• Produits de l’écosystème

Leurs besoins sont :

• Utilisateurs : avoir de la visibilité sur les prochaines fonctionnalités, donner du feedback, comprendre comment utiliser le produit;
• Equipe : comprendre le sens, avoir de la visibilité sur la suite des activités;
• Sponsor : constater l’avancement et être rassuré;
• Produits de l’écosystème : avoir de la visibilité sur les adhérences.

Comment répondre à ces besoins d’information et qu’est-ce que cela va apporter au produit ?
Mes premières pistes de réponses étaient les suivantes :

• Product vision board
• Roadmap
• Démonstration
• Release note

J’ai décidé de me faire aider de l’intelligence collective d’EKITE pour avancer.
Nous avons donc fait un brainstorming lors d’une session de veille commune autour de ce sujet et voici le résultat obtenu:

J’ai choisi de mettre de côté Yammer, Identité visuelle, Newsletter, Sharepoint (site) et Webinaire qui semblent plus être des canaux pour passer l’information. Je préfère que nous en fassions abstraction comme ce choix peut être très dépendant de l’organisation de chaque entreprise et de ses outils de messagerie ou réseaux sociaux en place.

Les points remontés qui me semblent très intéressants et que j’ai donc ajoutés à la liste sont :

• Documentation
• Evènements
• Club utilisateurs

Détaillons maintenant ce qu’apporte chaque élément

Product Vision Board

Le Product Vision Board va apporter une vision haut niveau plutôt stratégique du produit. Faire ce travail et le diffuser très largement va permettre de fédérer autour d’une vision commune. Nous savons vers quoi nous allons et nous en ressortons même avec un pitch du produit dans la partie haute du vision board.
Le sponsor et l’équipe vont être les principaux bénéficiaires de ce board; il permet de s’assurer que l’équipe va dans la bonne direction.

Roadmap

La roadmap apportera une vision plus concrète des différents sujets à traiter et des premiers jalons. Plus bas niveau que le Product Vision Board, nous sommes ici dans le concret de ce qu’apportera l’équipe comme feature sur les prochains mois. Il faut toujours la communiquer sans s’engager trop loin au risque de sortir du cadre de l’agilité et de perdre la notion d’engagement de l’équipe. La roadmap donnera une vision à l’équipe des prochains sprints à venir, elle rassurera le sponsor sur la capacité de l’équipe à délivrer et donner une vision aux autres produits de l’écosystème des sujets d’adhérence. La communiquer avec les utilisateurs peut aussi permettre de tempérer les attentes sur d’autres sujets; voir que l’équipe avance sur d’autres sujets explique le délai d’attente d’autres demandes. Il faut juste toujours faire attention à ne pas trop communiquer de dates lointaines pour ne pas générer de frustration.

Démonstration

La démonstration est un point clé du développement du produit. Elle permet à l’équipe de présenter le résultat de son travail et de récolter en direct du feedback pour que le produit corresponde au mieux au besoin. La présence des utilisateurs (ou d’un utilisateur clé) est donc vivement conseillée. Le sponsor sera en mesure de constater l’avancement, et les autres produits peuvent y participer ponctuellement pour des sujets spécifiques. Si les utilisateurs ne sont pas disponibles, il est toujours possible de diffuser une courte vidéo présentant les nouvelles fonctionnalités pour toucher plus d’utilisateurs.

Release note

La release note, dans la même veine que la démonstration, permettra de donner de la visibilité sur les fonctionnalités qu’apporte la nouvelle version. Sortir une version du produit après la démonstration permet de directement donner la main aux utilisateurs sur les nouvelles fonctionnalités présentées par l’équipe. Cette release note accompagnera tout cela et tracera les évolutions version après version. Faire attention toutefois à qui elle s’adresse. Une release note pour les utilisateurs ne doit pas forcément reprendre toutes les tâches techniques effectuées pendant le sprint sous peine de noyer l’utilisateur dans trop d’informations, le faisant passer à côté de la véritable valeur apportée par l’incrément.

Documentation

Il convient de définir ce que nous mettons derrière documentation : l’idée est de capitaliser sur les connaissances et de les partager. Il peut s’agir de documentation interne (technique à destination de l’équipe par exemple) ou externe (documentation pour l’usage du produit ou d’une api). Ce point remonté en brainstorming est crucial. Un produit correctement documenté est un produit plus facilement adopté, les utilisateurs sont guidés dans son utilisation et en comprennent plus facilement le sens. Une bonne documentation doit rester claire et succincte mais doit être mise à jour en même temps que le produit. Une bonne pratique est d’inclure la mise à jour de la documentation dans la « Definition Of Done » des stories. Les utilisateurs et les autres produits vont être les principaux bénéficiaires de cette documentation mais l’équipe elle même également.

Evènements

Plus ponctuels, les kick-offs ou afterworks produit sont l’occasion de rassembler autour du produit et de générer de l’intérêt. C’est l’occasion de rediffuser la vision et la roadmap. Nous pouvons montrer les dernières fonctionnalités et recueillir du feedback. L’adoption du produit est facilitée si les utilisateurs clés se sentent impliqués dans le processus de développement et le déroulement du projet.

Club utilisateurs

Je n’ai jamais mis le club utilisateurs en pratique, mais l’idée est de rassembler différents utilisateurs du produit pour leur présenter toujours les nouvelles fonctionnalités. Les utilisateurs peuvent partager entre eux leurs conseils de bonne utilisation et c’est très intéressant de ressortir de ces échanges ou interview avec des idées directement liées à leur utilisation au quotidien. Les irritants sont identifiés et les features clés sont mises en avant. Il est facile d’identifier des quick wins qui permettront de gagner la confiance des utilisateurs et d’en faire des adjuvants qui vont faciliter l’adoption du produit de manière plus large.

Pour conclure

Il semble qu’une bonne base pour apporter de la visibilité à tous les interlocuteurs serait de:

• transmettre une vision produit; elle doit être affichée et portée par le PO;
• afficher une roadmap et la tenir à jour;
• fournir une documentation facilement utilisable;
• faire des démos pour montrer l’avancement et accompagner les versions de release notes diffusées pour tracer les nouveautés;
• organiser des évènements pour fédérer autour du produit et trouver les adjuvants.

L’article Comment communiquer autour de son produit ? est apparu en premier sur EKITE.

L’article La facilitation : fourre-tout ou rôle hybride ? est apparu en premier sur EKITE.

FAST, c’est un framework d’Agilité à l’échelle proposé par Ron Quartel, coach Agile (entre autres) basé à Seattle et qui a eu l’occasion de développer cet outil à l’occasion de l’une de ses missions. L’objectif était de pousser à l’extrême la notion d’auto-organisation et de fluidité d’équipe (comprenez, les personnes ne font pas partie d’une équipe en particulier mais se réorganisent en permanence). Résultat, une vingtaine de pages pour décrire le fonctionnement d’une organisation plus ou moins étendue (jusque 150 personnes) avec des unités temporelles de 2 jours. Comment ça peut marcher ? On vous en dit plus tout de suite !

 

FAST, c’est-à-dire ?

 

Pour parler de FAST, il faut conjuguer Open Space Technology et Open Allocation. Comprenez, pour l’un, qu’il s’agit de laisser les personnes décider sur quoi il est préférable de travailler, dans un environnement colocalisé, et pour l’autre, qu’il s’agit de laisser les personnes s’auto-organiser sur la meilleure façon de travailler ensemble. Ces deux critères sont à la base de ce framework, combinée avec le découpage et l’animation du (des) produit(s). Celui-ci se rapproche d’un Story Mapping classique permettant de prioriser le travail à faire et de diffuser la vision produit.

Ces éléments vont donc permettre d’animer des cycles de valeur (et non pas des itérations) de 2 jours, dans lesquelles on trouve une seule réunion qui termine le cycle en cours et ouvre le suivant, en faisant à la fois le bilan du travail réalisé et en re-mélangeant le travail à faire.

Le diagramme suivant résume en quelques images le fonctionnement d’un cycle FAST (source twitter @FSTAgile) :

Déroulement d’un cycle FAST

 

OK, mais comment en savoir plus ?

 

Ron Quartel le créateur de FAST

L’avantage des outils qui se structurent, c’est que les personnes qui en sont à l’origine sont généralement disponibles pour en parler. Nous avons donc pu obtenir un rendez vous en visio avec Ron Quartel, le fondateur de FAST. En direct de Seattle où il était 6h du matin pour lui, nous avons pu faire connaissance, échanger et poser les questions que nous avions. Ron est quelqu’un de très curieux et accessible, on sent la volonté de contribuer au développement de l’agilité en apportant cette méthode issue de sa propre expérimentation et non la volonté de vendre un framework.

Fast est encore au stade de recherche et d’expérimentation, James Shore (auteur de « The art of Agile Development ») mène en ce moment des tests de FAST sur son projet. Plusieurs fois au cours de l’entretien Ron nous a répondu : « Il faudrait tester », loin de penser avoir toutes les réponses il nous propose d’apporter notre pierre à l’édifice en expérimentant nous-même et en contribuant. Il nous a même invité à proposer nos idées pour le nommage de certains détails qui pourraient être déceptifs (l’étape du Show & Tell notamment, à ne pas imaginer comme étant une Démo Scrum mais comme un passage en revue rapide).

Ron a insisté sur la notion de « bulle d’autonomie » : il est nécessaire d’avoir suffisamment de marge de manœuvre pour pouvoir mettre FAST en place. Il faut également un management qui laisse de l’espace et qui autorise l’expérimentation. Son seul regret sur son expérimentation est le changement de management qui a mis fin à cette aventure. Il nous a parlé de « TEAL management » qui est le dernier stade d’évolution d’une organisation qui s’approche de l’auto-gouvernance d’après Frédéric Laloux (dans Reinventing Organizations : Vers des communautés de travail inspirées).

La gouvernance de l’équipe

Nous avons aussi pu parler de l’importance de lancer cette approche accompagné de personnes volontaires et motivées par ce mode de fonctionnement, tout le monde n’est pas demandeur de plus d’autonomie et cela peut être un frein au lancement de FAST. Dans la dimension humaine toujours il a plusieurs fois insisté sur l’importance de très vite se mettre d’accord sur la notion de « Tribe Agreement » (comment les décisions seront prises ensemble et comment les conflits seront résolus ) pour avancer sereinement vers la suite.

Certaines de nos questions touchaient à l’autonomie et aux problèmes qui auraient pu en découler, nous étions curieux par exemple de savoir si les tâches de run n’étaient pas délaissées, si les tests et les release se faisaient également en bonne harmonie. Le problème ne s’est jamais présenté sur son projet, l’expérimentation de Fast avait justement démarré parce que plusieurs produits étaient gérés en parallèle par son équipe et qu’il ne voulait pas « punir » les plus anciens développeurs en les faisant travailler sur la partie Legacy. En affichant tout sur la Product Map toutes les tâches sont identifiées (même les tests ou les release apparaissent, il n’y a pas de tâche implicite) et l’équipe se les répartit en bonne intelligence sans besoin d’assignation de la part du Product Manager. La notion de responsabilité collective est plusieurs fois revenue.

L’ajout de règles de fonctionnement supplémentaires se fait quand et si nécessaire, Ron a pris l’exemple de la partie Run qui a été affichée à part sur un kanban par son équipe pour plus de visibilité.

 

L’article FAST (& Furious) Agile, c’est déjà le futur est apparu en premier sur EKITE.

L’article Shape Up, qu’en pense le tech lead après 8 mois ? est apparu en premier sur EKITE.

Le constat

Dans l’univers impitoyable de l’agilité (c’est légèrement abusé comme vision), tout le monde parle des frameworks existants et émergents, des pratiques et des outils à connaître pour être un bon Product Owner ou un Scrum Master de qualité.

Est-ce suffisant ? ????

Bof. ?

Pas certain. ?

Quand nous regardons le manifeste agile, tout ceci reste quand même éloigné des valeurs initiales :

1) Les individus et les interactions plus que les processus et les outils

2) Des logiciels opérationnels plus qu’une documentation exhaustive

3) La collaboration avec les clients plus que la négociation contractuelle

4) L’adaptation au changement plus que le suivi d’un plan

Oh, tiens. Dans le manifeste, il est plus question d’attitude, de posture et de comportement que de certification Scrum ou autre maîtrise de SAFe, par exemple. Oui, le manifeste parle bien de Soft Skills. ?

Soft Sk-quoi ?

Pour ceux qui ne le savent pas, les softs Skills désignent des compétences comportementales. Et elles ne sont pas acquises uniquement dans un cadre professionnel.

Elles s’acquièrent aussi dans la vie privée, sociale, associative, etc.

Nous avons constaté que chaque rôle estampillé agile nécessitait un socle important de Soft Skills.

Pourquoi ?

Parce que ce sont des rôles d’animation et de facilitation, nécessitant des postures de fédération et de connexion.

Par exemple, nous attendons d’un Scrum Master qu’il soit capable de lever des obstacles, au Product Owner de comprendre des besoins des utilisateurs et au coach d’écouter activement tout le monde et de proposer des conseils ajustés.

Nos convictions

Chez Ekité, nous trouvions que les outils d’évaluation des Soft Skills sur des rôles agiles (et pas seulement) étaient inexistants. Et c’était un peu triste.

C’est pour cela que nous vous proposons librement cet outil “Soft Skills Detector”.

Il se compose de plusieurs items :

• Une règle du jeu initiale (à vous de tordre le modèle si nécessaire ? )

• Un jeu de cartes catégorisées, avec de nombreuses Soft Skills

• Un plateau de tri sous format MoSCoW

• Un Radar pour situer un profil

Vraiment, c’est joli. Et c’est pratique en plus.

Nos radars définissants les Soft Skills nécessaires pour chaque rôle ne sont pas mis à disposition.

Ils appartiennent à la vision d’Expert Agile d’Ekité et restent propres à notre identité. Nous sommes persuadés qu’ils seront probablement différents d’une entreprise à une autre.

Ceci vous rend triste ?

Pas de problème, nous sommes prêts à vous accompagner sur la création de vos propres radars références et sur l’animation de Soft Skills Detector?

Les règles du jeu

• Le candidat lit l’ensemble des cartes « Soft Skills » et pose des questions en cas de doute sur le sens

• Le candidat sélectionne 15 cartes, qu’il pense adaptées à lui-même.

• Le candidat classe ses 15 cartes dans les 4 catégories : Must, Should, Could & Won’t

• Les cartes sont placées sur la matrice Soft Skills. Cette matrice est confrontée aux matrices liées au rôle de l’agilité ciblé par la personne.

• Les delta sont identifiés, discutés et partagés.

• Un plan d’actions peut être défini à la fin de la session.

Nos Livrables

Template Soft Skills Detector – format rtb (export de Miro)

Grille d’évaluation de Soft Skills Detector (fichier Excel)

Les cartes Soft Skills en pdf

Source

Pour les Soft Skills : https://blog-bloomr.org/2021/07/01/liste-46-soft-skills/

L’article Soft Skills Detector – un outil d’évaluation by EKITE est apparu en premier sur EKITE.