Qu’est-ce qu’un Scrum Master ? (Agile en Seine 2017)

Voici un retour un peu tardif sur les conférences de Agile en Seine du 20 septembre 2017 et notamment sur la présentation de Romain Couturier sur « Qu’est-ce qu’un Scrum Master ?« . J’ai réalisé un petit dessin qui centralise ce que j’ai retenu et je l’ai publié sur linkedIn dans un POST. Mais comme il est parfois difficile de retrouver les informations dans le flux dense du réseau social, je republie ce dernier ci-dessous 😉

20170920-scrummaster

Je vous propose aussi de pouvoir approfondir le sujet avec l’article de Jean Claude GrosJean, « Le ScrumMaster n’est pas un Coach Agile« 

 

Publicités

L’estimation et la planification agile

L’une des valeurs du manifeste Agile est de favoriser l’adaptation par rapport à un plan établi. Cette valeur est parfois mal interprétée et ne signifie pas qu’il ne faut pas planifier. Mike Cohn nous explique dans Agile Estimating and Planning les raisons pour lesquelles il est nécessaire pour une équipe Agile de planifier.51I7-xMCQDL._SX408_BO1,204,203,200_

Dans mon expérience, j’ai rencontré plusieurs équipes qui se demandaient comment il fallait planifier et surtout comment estimer les stories. Faut-il estimer en point, en jours idéaux, avec la suite de Fibonnaci ? L’estimation du travail est souvent source de tension ou de conflit entre l’équipe de développement et les commanditaires du projet ou encore avec le Product Owner. Mais avant de se poser la question du « comment? », j’invite les équipes à revenir sur le « pourquoi? ». Pourquoi estimer ? A quoi et à qui cela sert ?

Mike Cohn nous explique ces raisons dans Agile Estimating and Planning. Un plan doit permettre de :

  • guider les décisions des investissements à réaliser.
  • savoir si un projet est sur le point de livrer des fonctionnalités que les utilisateurs attendent.
  • connaître le nombre de ressources disponibles pour travailler sur ce projet pendant une période définie.

Planifier est souvent difficile et les équipes peuvent tomber dans les deux extrêmes de ne pas planifier du tout ou de trop planifier. Planifier est une activité difficile et le cône d’incertitude ci-dessous nous démontre combien il est difficile d’estimer le projet dans les premières phases de ce dernier. A la définition du projet, l’incertitude est de 60% et il faut attendre le design détaillé pour réduire cette incertitude à 10%. Ce qui explique donc que plus de 2/3 des projets dépassent le coût estimé initialement.

coneOfUncertainty

Mais alors si cela est si difficile de planifier un projet, pourquoi effectuer cette activité ? Et bien tout d’abord pour :

  • réduire le risque : les discussions qui servent à estimer le projet permettent de mettre en lumière les potentiels risques du projet.
  • réduire l’incertitude : un des risques les plus importants d’un projet n’est pas de ne pas sortir dans les temps mais bien de développer des fonctionnalités qui ne répondent pas aux besoins des utilisateurs. Ce risque peut être atténué via une planification agile continue qui permet de récupérer les retours utilisateurs au fur et à mesure du projet.
  • aider à prendre de meilleures décisions : l’estimation du coût d’un projet et de sa valeur métier nous permet de décider si le projet doit être lancé.
  • établir la confiance :  les fréquentes livraisons de fonctionnalités permettent d’établir la confiance entre le client et les développeurs. Les estimations deviennent de plus en plus fiables au cours des itérations et permettent de prioriser les fonctionnalités en se basant sur l’estimation fiable de l’équipe de développement.
  • transmettre de l’information : un plan ne garantit pas la livraison d’un périmètre à une date précise mais permet néanmoins de fixer un niveau d’attente et l’approche pour arriver à satisfaire cette attente.

Maintenant que nous savons à quoi sert la planification et l’estimation agile, nous pouvons insister sur le « comment ». Certaines équipes estiment leurs stories en point de complexité/d’effort alors que d’autres les estiment en jours idéaux. Les jours idéaux sont des jours où chaque membre de l’équipe consacrerait 100% de son temps de travail dans la journée à la story sans être dérangé par d’autres activités professionnelles.

Les partisans du chiffrage en points mettent en avant que ce type de chiffrage :

  • permet aux équipe multi-fonctionnelles de pouvoir avoir une mesure commune.
  • est constant dans le temps, ne dépend pas du niveau de capacité ou de compétence de la personne qui va réaliser la story.
  • est une pure mesure de taille et ceci permet donc de pouvoir chiffrer par analogie, de manière relative. De plus, comme cette mesure est complétement abstraite, les équipes ne devraient pas être tentées de comparer cette estimation avec du temps passé.
  • est plus rapide grâce notamment à la possibilité de comparer de manière relative par analogie avec des stories de référence.

Enfin, les jours idéaux varient d’une personne à une autre. Cependant,  il est plus facile d’expliquer un chiffrage en jours idéaux aux personnes extérieures à l’équipe et pour une équipe qui débute, ce mode de chiffrage est plus facile à appréhender.

L’action de planification pour une équipe agile s’effectue à plusieurs horizons et plusieurs niveaux d’abstraction. L’action de planifier revient à se fixer des objectifs sur une période donnée et à les réviser tout en décalant des objectifs plus long terme. Pour une équipe qui travaille en SCRUM, l’équipe va fixer un objectif de release avant le premier sprint et réviser ce dernier au fur et à mesure des sprints. En effet, la release va être initialement estimée et planifiée puis revue à la fin de chaque itération pour évaluer comment le périmètre associé à la date évolue. L’action ici sur le périmètre du sprint a une influence sur le périmètre de la release. On parle ici de planification en couches successives ou en oignon.

Le dernier point détaillé par Mike Cohn que je souhaiterais partager est celui du niveau de détail de l’estimation et de la planification. A quel moment et niveau de détail faut-il arrêter de planifier ? Cette question peut aussi se poser dans un projet en cycle en V et j’ai déjà par le passé fait l’amère expérience de trop planifier un projet. Ce problème se présente par le fait de planifier de toutes petites tâches et donc de planifier tout le temps. Planifier devient alors l’activité principale et l’information portée par ce niveau de détail n’apporte pas assez de plus-value au projet. Mike Cohn nous explique ce travers avec le petit exemple suivant : « si vous vous demandez combien de cookies j’ai mangés l’an dernier, vous avez plusieurs options pour répondre à cette question :

  • Estimer le nombre de cookies au hasard
  • Demander à mes proches, mes amis, ma famille
  • me suivre pendant une journée, compter combien je mange de cookies et extrapoler sur un an.

Cependant, si votre but est de savoir si vous pouvez m’offrir ou non, une boîte de cookies, alors vous n’avez pas besoin d’avoir une mesure ultra précise et il n’est donc pas nécessaire d’effectuer trop de recherches. Dans ce cas précis, la première solution pourra convenir. Quand on planifie, il faut donc toujours se demander dans quel but afin d’évaluer le niveau d’effort et de détail que nécessite cette planification.

Je vais vous décrire une situation que j’ai déjà rencontrée et qui peut s’avérer être un parfait exemple d’une planification peu « agile ». Lors d’un projet avec un centre de service, j’ai travaillé avec une équipe qui chiffrait les stories en points en utilisant la suite de Fibonnaci. L’équipe n’était pas dédiée et le nombre de point d’une story, convertie par un coefficient donnait directement le nombre de jours et donc le coût de la story. L’équipe allouait un nombre/capacité de points différent à chaque itération qui représentait donc directement le nombre de jours pendant lesquels l’équipe allait travailler sur le produit. Cette situation peut aboutir à plusieurs effets pervers :

  • Comme l’équipe estime une capacité ou un coût de story fixe et que celui-ci représente le nombre de jours de travail sur la fonctionnalité, il n’est plus possible de lisser entre les stories d’un même sprint.
  • Comme l’équipe estime avec la suite de Fibonnaci et que les stories sont directement converties en jours/homme, une story légèrement supérieure à 8 passe à 13, ce qui n’est pas du tout le même coût : le commanditaire se sent lésé.
  • Comme les développeurs estiment chaque story et prennent un engagement sur chacune d’elles, ceux-ci ont tendance à se protéger et réhausser leur chiffrage.
  • Comme l’équipe n’est pas dédiée et que la capacité change à chaque itération, on perd la possibilité d’apprendre au cours des sprints.
  • Le fait de ne pas estimer de release et de changer la capacité à chaque itération supprime toute possibilité de planification.

Cette situation aboutit donc à une forte tension entre le commanditaire et l’équipe de développement. Sans compter que ceci rajoute aussi de la pression sur les développeurs qui doivent prendre un engagement à la story. Ce pattern qui favorise un rapport contractuel et impose une facturation à la story est selon moi anti-agile.

Liens et Références :

MVP et Design Sprints

Aujourd’hui, je voudrai vous parler de MVP; Minimum Viable Product (ou Produit Minimum Viable en français). On en entend souvent parler autour de nous et notamment lorsqu’un projet débute. Le MVP permettrait au Responsable de Produit (PO) d’apporter le maximum de valeur métier à ses utilisateurs en un minimum d’effort de la part de l’équipe qui réalise le produit ; effort souvent limité aux premiers sprints. De nombreuses Entreprises de services numériques (ESN) proposent donc d’échelonner leurs réalisations suivant ce MVP.

Mais qu’est-ce que le MVP ? Wikipedia n’est pas très loquace sur le sujet : « stratégie de développement de produit, utilisée pour de rapides et quantitatifs tests de mise sur le marché d’un produit ou d’une fonctionnalité » et nous renvoie notamment vers Eric Ries auteur de  The Lean Startup. Pour simplifier, le Processus du Lean Startup se base sur les trois composantes suivantes :

  • Build qui est l’étape de la construction methodology_diagramdu produit ou de la fonctionnalité
  • Measure qui est l’étape ou on mesure la plus-value de la fonctionnalité ou du produit construit à l’aide de métriques.
  • Learn qui est l’étape où on apprend auprès des utilisateurs et où on récupère leur feedback sur l’utilisation du produit ou de la fonctionnalité.

Le MVP est donc un outil ou une stratégie qui permet de mesurer la pertinence d’un produit ou d’une fonctionnalité auprès des utilisateurs concernés sans avoir pour autant besoin de construire ces derniers. Alexander Cowan dans son cours Running Product Design Sprints, nous explique que le MVP est utilisé pour tester la motivation des utilisateurs pour une fonctionnalité et valider des hypothèses concernant la plus-value métier de cette dernière. Les différents outils ou véhicules qu’il propose sont les suivants :

  • Sales vehicle :  technique qui consiste à vendre la fonctionnalité ou le produit. Il n’y a pas d’interaction entre les utilisateurs et la fonctionnalité ou le produit. Cette technique peut se matérialiser par un envoi de mail aux utilisateurs, par une page de publicité sur un site, par un sondage, un formulaire…
  • Wizard of Oz vehicle : technique qui consiste à présenter le produit/fonctionnalité ou du moins une interface qui va simuler le fonctionnement du produit ou la fonctionnalité. Cette technique peut se matérialiser par une démonstration, une présentation animée, un webinar ou encore une vidéo…
  • Concierge vehicle : technique qui consiste dans le fait de fournir la fonctionnalité à l’utilisateur, même si cette fonctionnalité est offerte manuellement. Cette technique ne nécessite pas forcément la construction du produit ou de la fonctionnalité finale.

Ces 3 techniques peuvent être combinées afin de valider les hypothèses de plus-value  formulées pour résoudre les problèmes utilisateurs et de nombreuses entreprises les ont utilisées avant d’investir des fonds dans la construction de leur produit ou des fonctionnalités.

Voici quelques exemples décrits dans le cours Running Product Design Sprints :

  • Les créateurs de DROPBOX ont commencé en publiant une démo sur YouTube puis en intégrant cette vidéo dans une page web avec un formulaire  pour récupérer des signatures : on reconnaît ici une combinaison Wizard of Oz et Sales.
  • Le créateur de ZAPPOS, le site de vente de chaussures online, Nick Swinmurn a commencé en prenant une photographie d’une paire de chaussures  et en la postant sur un site web pour savoir si des personnes achèteraient cette paire de chaussures. Une fois que les clients ont acheté la paire de chaussures, ils ont pu recevoir celle-ci à leur domicile. Le MVP utilisé  est le Concierge.
  • SPRIG est une entreprise de préparation et de livraison de plats préparés. Les créateurs se sont organisés dans une cuisine temporaire pour préparer des plats. Ils ont envoyé des mails à leurs amis et ont ensuite vendu les plats grâce au site EventBrite. Ils ont pu ainsi mesurer le succès de leur idée. Nous sommes ici dans un cas de Concierge puisque les utilisateurs ont pu expérimenter le service.

On peut trouver de nombreux autres exemples sur le net : Twitter, Groupon…Mais le but d’un MVP est d’apprendre et de valider des hypothèses sur les utilisateurs et selon Alexander Cowan, le Concierge MVP est celui qui permet d’en savoir le plus. Les habitudes des utilisateurs peuvent être mesurées sur le produit grâce à des tags et des indicateurs…Des interviews peuvent aussi compléter ces données.

Pour revenir au début de l’article, je ne suis pas certain qu’on puisse vraiment parler de MVP dans le cas où on construit un produit mais où on ne valide aucune hypothèse sur les utilisateurs. Le but du MVP, ne l’oublions pas, est de valider la pertinence du service proposé aux utilisateurs, en un minimum de temps et d’investissement.

Liens et Références

Agile Playground #27

Merci encore à GOOD de nous avoir reçu mardi dernier, dans ses locaux pour le premier Agile Playground après les vacances d’été. Nous étions bien plus d’une vingtaine pour cette rentrée Agile Playground. Nous avons commencé la soirée par un petit Icebreaker : le nombre secret, vous connaissez ? Chaque personne note un nombre sur un post-it et le garde secrètement. Il doit ensuite le faire deviner aux autres participants sans parler et sans dessiner ce nombre afin d’obtenir finalement une chaîne ordonnée de personnes du plus petit au plus grand nombre.

Nous avons ensuite commencé les jeux. parmi les jeux proposés, nous avions le choix entre :Carpaccio, mener un sprint planning en DUPLO, utiliser les Rory’s cubes pour une rétrospective, les vaginales; un jeu de cartes sur le concept du mille bornes et traitant du plaisir féminin. C’est bête, je n’ai même pas eu le temps de discuter avec les créateurs du jeu. On aurait pu s’échanger des tuyaux sur la création d’un jeu de cartes.

J’ai pour ma part décidé de participer au jeux de planification de sprint et au jeu d’utilisation des Rory’s cubes pour une rétrospective. Les deux jeux étaient animés par Daniel Paire et la soirée fut riche en information et en enseignements.

Revenons au premier jeu ou comment faire estimer un sprint backlog à l’aide de DUPLO. Daniel nous a expliqué que pour des équipes relativement novices en SCRUM, il modélisait la vélocité réelle d’un sprint en construisant une tour en DUPLO (parce que les DUPLO de sa fille sont plus gros que les Lego classiques et qu’il en faut donc moins pour faire une tour). lego_duplo_5538_z1Une fois la tour de vélocité construire et le PO positionné sous la forme d’un animal au sommet de celle-ci afin de signifier par la symbolique que la tour appartient au PO, Daniel a construit des tours plus petites, de différentes tailles; 1 à n DUPLO afin de modéliser les différents coûts d’une story; XS, S, M, L, XL. Il a ensuite créé une liste de stories et nous avons pu commencer à les évaluer. Il a intentionnellement créé une story de grande taille avec de nombreuses contraintes fonctionnelles afin que nous l’évaluions à la taille XL et que nous puissions nous rendre compte que celle-ci était visuellement plus grande que la moitié de notre tour de vélocité. Nous avons donc découpé cette story en stories plus petites. Les développeurs ne connaissent pas le rapport entre la taille de la tour et la vélocité réelle. ceci permet donc à ceux-ci de pouvoir estimer librement sans être tenté d’effectuer une conversion  en jours/homme. Le jeu permet aussi de donner un rythme différent et d’apporter un peu de nouveauté à ce rituel qui peut parfois être long et fastidieux. Daniel nous l’a affirmé : « si un développeur commence à estimer le rapport de conversion entre la tour DUPLO et la vélocité, alors il le changera aussitôt ». Mais alors me direz-vous , comment savoir si on suit la release planifiée. Daniel possède un fichier Excel qui lui permet de  convertir les DUPLO en vélocité réelle pour détecter toute variation par rapport à la planification! Il envoie la vélocité réelle au Product Owner…

Le deuxième jeu auquel j’ai participé est l’utilisation des Rory’s cubes pour l’animation d’une rétrospective. Ce jeu a tout d’abord été inventé par un psychologue Danois afin de susciter la créativité et l’imagination des enfants qui doivent inventer des histoires à partir de dés.

rorys-story-cubes

Le jeu est constitué de 3 séries de 9 dés. Dans un premier temps, chaque personne de l’équipe va lancer à tour de rôle les trois séries et retenir 3 dés pour chaque série.

  • A partir des 3 premiers dés, la personne doit indiquer quelque chose qu’elle a aimé ou non dans le sprint passé en utilisant le modèle : « dans le dernier sprint j’ai aimé… je n’ai pas aimé… »
  • A partir des 3 dés de la seconde série, la personne doit imaginer une solution pour faire perdurer ce qu’elle à aimé ou résoudre ce qu’elle n’a pas aimé.
  • La troisième série de 3 dés permet de définir une action concrète à réaliser pour mettre en oeuvre les solutions de la seconde série.

Dans un second temps, l’équipe va garder un seul dé de chaque série et inventer une histoire collective; cette seconde partie permet de travailler sur la cohésion d’équipe.

Une chose est sûre, ces deux activités permettent de rompre la monotonie que l’on peut parfois ressentir lors des rituels SCRUM. Merci Daniel pour cette soirée sympathique et pleine d’enseignements.

 

Une autre vision des user stories

Qu’est-ce qu’une bonne user story ? Est-ce un petit morceau de spécifications fonctionnelles ? Quel est le niveau de détail d’une user story ?

Beaucoup d’articles traitent de la construction des user stories mais j’ai récemment compris comment celles-ci expriment les valeurs de l’agilité. J’aime bien le fait qu’une user story soit définie comme une invitation à la communication ; comme un outil de conversation et de collaboration. Donc une user story n’est pas un petit bout de spécifications ; inutile d’essayer de tout préciser sur un petit bout de post-it. Cependant, la user story doit permettre de développer un logiciel ou construire un produit qui correspond aux besoins de l’utilisateur. J’ai récemment suivi un MOOC sur la construction des user stories selon les besoins des utilisateurs que j’ai trouvé intéressant et que je souhaitais partager avec tous ceux qui doivent construire un backlog de stories : ‘Getting Started: Agile Meets Design Thinking’ sur Coursera. Alexander Cowan et son équipe nous apprennent dans ce MOOC comment construire de belles user stories en se basant sur l’expérience utilisateur et sur le Venture Design Process.

2016-09-16-21_37_10-venture-design-process

Le Processus est très bien défini dans le site précédent mais voici pour ma part les quelques éléments que j’ai choisis de retenir selon mon expérience :

Les Personas, quand ils sont construits de manière rigoureuse, permettent de mieux comprendre les besoins utilisateurs. Ils constituent le point de départ du processus. Les Personas sont en général élaborés lors du cadrage du projet et permettent ensuite d’écrire les premières stories du backlog. Quand ils sont enrichis et utilisés tout au long du projet, les Personas sont une véritable source d’inspiration pour définir les user stories.

  • Afin de vous aider à construire les user stories à partir des Personas, vous pouvez commencer par exprimer des scénarios décrivant les problèmes auxquels font face les Personas et les alternatives qu’ils ont trouvées pour les résoudre .
  • Vous pouvez ensuite proposer des solutions qui apporteront une valeur ajoutée par rapport aux alternatives.
  • Puis vous pouvez construire des prototypes sous forme de storyboards pour expliquer la solution et sa valeur ajoutée. Ceci vous permet aussi de revenir et d’affiner votre proposition. L’outil StoryBoardThat permet de construire rapidement des storyboards efficaces qui vous permettront d’expliquer vos solutions.

Quand on respecte rigoureusement ces étapes, on se concentre davantage sur la compréhension des besoins utilisateurs que sur la mise en oeuvre de la solution. Et c’est là que cela devient intéressant. Pourquoi ?  Et bien parce qu’on va éviter le syndrome du « bouton bleu ».  Le syndrome du « bouton bleu », c’est quand on obtient une story du type : « en tant que.. je veux appuyer sur le bouton bleu afin [d’effectuer une action]. « Cette story est précise », me direz-vous ? Oui, un peu trop précise! Cette story ne laisse à l’équipe de développement et au designer, aucune chance d’exprimer leur créativité et d’être force de proposition :

  • Aucune chance d’être force de proposition car on n’a pas la clause qui exprime la plus-value apportée à l’utilisateur.
  • Aucune chance non plus de proposer la solution technique qui permettrait de réaliser la fonctionnalité exprimée.

Vous serez d’accord pour reconnaître que cette story laisse peu de place pour la confiance et la collaboration des personnes. Cette story construite selon le très célèbre format, « en tant que [] je veux [] afin de [] « , ne respecte pas les valeurs de l’agilité et peut être démotivante pour les équipes. Le format ne fait pas tout 😉

Alors d’accord, on va laisser les équipes collaborer et concevoir de manière collective. Mais il y a quand même des contraintes fonctionnelles et métier… Et c’est là que les cas de tests d’acceptance rentrent en jeu, pour exprimer ces règles métier.

Ex : Pour une recherche, s’assurer que l’on peut rechercher par date.

Alors oui, les stories sont INVEST, 3C… mais c’est avant tout un moyen de collaborer et communiquer avec :

  • les utilisateurs ou ceux qui les représentent.
  • les personnes qui vont réaliser les stories.

C’est en quelque sorte le format pivot entre les besoins et le produit réalisé.

 

 

 

L’intelligence collective suite

Bonjour,
Il y a quelques semaines, j’ai participé à un atelier sur l’intelligence collective et lorsque j’ai trouvé ce numéro de Cerveau & psycho magazine (numéro 78), j’ai pensé que c’était un heureux hasard. cerveau_psychoOù alors, le terme serait-il un buzz du moment ?

Ce magazine consacre tout un dossier sur « Les clés de l’intelligence collective » et a été écrit par Estelle Michinov, professeure de psychologie sociale à l’université de Rennes 2.
Voici un petit résumé de l’article :
Les modes de travail et les organisations poussent de plus en plus au travail collectif et plusieurs facteurs peuvent influencer l’efficacité d’un groupe: nature des tâches,  composition des équipes, règles de fonctionnement ou procédés en vigueur au sein d’une communauté. Grâce au psychologue Ivan Steiner, nous pouvons depuis 1972, identifier 4 types de tâches :

  • les tâches additives où les contributions individuelles s’additionnent et où le rendement du groupe dépasse celui du meilleur de ses membres. Exemple du tir à la corde.
  • les tâches compensatoires où la performance du groupe dépend de la moyenne des contributions et où le rendement dépasse souvent celui d’une partie de ses membres. Exemple de l’évaluation d’un candidat par un groupe.
  • les tâches disjointes où le rendement peut reposer sur la réponse d’un seul membre, le plus compétent. Exemple de résolution d’énigme.
  • les tâches conjointes où la réussite du groupe dépend de l’union des efforts de chacun et où le rendement peut dépendre de la contribution du membre le moins compétent; Exemple d’un groupe d’alpinisme où le plus lent ralentit le groupe.

L’intelligence collective se développe plus ou moins selon ces types de tâches et on sait aujourd’hui que les tâches conjointes sont plus propices au travail d’équipe.

Mais alors, qu’est-ce qu’une équipe intelligente ? Des travaux de recherche ont montré qu’une équipe avec des compétences et des styles cognitifs hétérogènes sont plus efficaces pour réaliser des travaux collectifs que celles qui sont constituées de membres à la personnalité trop proche.

Du coup, peut-on mesurer le QI d’un groupe, de la même manière qu’on mesure le QI d’une personne ?
Un collectif de personnes possède-t-il lui aussi une capacité générale et transversale de résolution, indépendante de la nature de la tâche et reflétant son intelligence propre ? Anita Woolley de l’université de Carnegie-Mellon de Pittsburgh a mené une série d’études auprès de 200 groupes de personnes qui furent soumis à des tâches variées et les résultats ont révélé l’existence d’un facteur déterminant de la performance collective qui expliquait 43% de la variabilité des performances des groupes. Le facteur « c » défini comme la capacité du groupe à réaliser une grande variétés de tâches. Les groupes les plus intelligents se caractériseraient par de nombreux tours de parole: les équipes résolvent mieux les problèmes si la communication est équitable. La communication décentralisée est aussi liée à la sensibilité sociale qui se caractérise par la capacité des membres d’un groupe à savoir ce que pensent ou ressentent les autres en observant leur regards, attitudes ou expressions faciales. Le dernier facteur serait la proportions de femmes dans un groupe; ceci grâce à la dimension de sensibilité sociale des femmes.

Un des aspects de l’intelligence collective les plus étudiés ces dernières années est la capacité des individus à partager des modèles mentaux communs pour créer des équipes efficaces. Une forme particulière de modèle mental est appelé mémoire transactive…La mémoire transactive peut être favorisée par la nature de la tâche, la taille du groupe, les interactions spontanées…La mémoire transactive semble également bénéficier de certains profils psychologiques dans le groupe; des personnalités assertives (capable de s’imposer, de dégager de la confiance et d’impulser des projets). Il est enfin possible d’influencer l’état d’esprit des participants pour favoriser une bonne mémoire transactive. Pour développer celle-ci, les groupes peuvent avoir recours au team building ou au team training. Les activités de team training qui ont pour objectif de faire travailler les membres des équipes sur les compétences psychosociales nécessaires pour travailler en équipe, le leadership, la coopération, la gestion du stress et de la fatigue, la prise de décision ont des effets bénéfiques sur la performance collective.

Pour conclure, la synergie de groupe émerge de ce dernier quand un certain nombre de conditions sont réunies.

L’intelligence collective

J’ai participé mardi, il y a une semaine, à un Meetup chez Wemanity sur l’intelligence collective. Eric Baudet est venu spécialement de Nice pour nous présenter cette notion mais surtout pour nous la faire vivre et ressentir. Après quelques présentations de concepts et notamment le fait que nous n’utilisons seulement que 25% de notre intelligence cognitive pour 75% de notre intelligence somatique (du corps, du ressenti), il nous a appris qu’il existait une dernière intelligence : « l’intelligence du champ » qui découle des interactions entre les individus et le système qui les entoure, avec l’exemple qu’une idée pourrait se propager sous la forme d’une onde que nous pourrions capter.

Nous avons ensuite disposé les chaises en rond afin d’aborder le premier exercice qui consista à nous plonger dans l’état COACH :

  • C pour Centré
  • O pour Ouverture
  • A pour Alerte
  • C pour Connecté
  • H pour Hospitalier

Vu d’un oeil novice, se plonger dans un état COACH ressemble un peu à de la méditation. On s’accorde une écoute de soi pour ensuite être pleinement conscient de l’environnement qui nous entoure et pouvoir être réceptif aux ondes qui pourraient être envoyées par les personnes autour de nous (mon interprétation).

Une fois reposés et calmes, nous avons alors abordé un deuxième exercice en petit groupes qui consista à définir les facteurs de succès d’une équipe agile avec leurs niveaux de résonance :

  • Résonance négative quand deux personnes ont des comportements ou des ondes qui s’opposent.
  • Résonance positive quand deux personnes ont des ondes qui s’amplifient mutuellement.

Puis chaque porte parole de groupe a présenté le résultat des travaux à tout le monde en expliquant ses ressentis et les échanges à l’intérieur de chaque groupe.

Je n’ai pas pour ce qui me concerne, réussi à me plonger dans cet état de réception des ondes collectives  même si a un moment, les idées du groupe étaient complémentaires. Est-ce que l’homme à l’image des poissons ou des insectes, a la capacité, comme nous le témoigne Eric Baudet, de développer cette intelligence collective?

Merci à Eric Baudet pour cette expérience intéressante.