Le paradoxe du chimpanzé

Le paradoxe du chimpanzé (The Chimp Paradox) est un livre de Steve Peters sous-titré : La science de notre esprit pour des succès personnels et professionnels (The Science of Mind Management for Success in Business and in Life).

Lorsque j’ai utilisé cette représentation du fonctionnement de notre cerveau lors des conférences que j’ai données sur la recherche du bonheur, j’ai eu des retours très positifs sur la simplicité et la puissance de la représentation.

TheChimpParadoxDans cet article, je souhaite vous en dire un peu plus, et peut-être vous inciter à lire l’ouvrage de Steve Peters.

Le livre est une exploration d’un système solaire, le soleil est l’endroit où vous voulez être, les planètes représentent des zones à explorer : vous-mêmes, les autres, la communication, le stress, le succès, le bonheur, la confiance, la sécurité.

La première planète se nomme la planète divisée, elle représente notre esprit, notre façon de fonctionner, et la lutte à l’œuvre entre notre humain et notre chimpanzé.

Le modèle de représentation de l’esprit humain proposé par Steve Peters est simple. Il est composé de 3 éléments :

  • l’humain : c’est nous-même, la machine à penser de notre lobe frontal
  • le chimpanzé : c’est notre machine à émotions qui vit dans notre système limbique
  • l’ordinateur : c’est notre lieu de stockage et de gestion des réponses automatiques

Si nous observons comment un humain va réagir face à une situation : il va tout d’abord regarder ce qu’il a fait pour générer ce problème, ensuite il va observer les circonstances pour comprendre leurs impacts sur la situation, et en dernier il va observer les autres et rechercher des options pour les aider à adapter leurs actions.

Si nous observons comment le chimpanzé va gérer la même situation, ce sera bien moins rationnel, et plus émotionnel, cela fonctionnera exactement à l’envers. Le chimpanzé va tout d’abord regarder ce que les autres ont fait et pointer du doigt leurs erreurs, ensuite il va regarder les circonstances pour les blâmer et en dernier il se regardera lui-même pour s’apitoyer sur son sort…

Le problème que nous avons à résoudre est que nous devons vivre au jour le jour avec notre chimpanzé intérieur qui se réveillera très rapidement (5 fois plus rapidement que l’humain) s’il sent un danger, et prendra la main sur la réflexion avec comme option les 3 F : Fight, Flight or Freeze, soit se battre, s’enfuir ou s’immobiliser dans l’espoir que le danger disparaisse.

Ce chimpanzé est bien le nôtre. C’est une partie de nous-même. Nous ne pouvons dire : « ah désolé, c’est mon chimpanzé », c’est exactement comme s’il s’agissait de notre chien, nous sommes responsables si celui-ci venait à mordre quelqu’un.

Le troisième élément du modèle introduit par Steve Peters est l’ordinateur. L’ordinateur, 20 fois plus rapide que l’humain à réagir, va prendre la main pour gérer les situations connues, il va donc nous soulager d’avoir à réfléchir et prendre de nombreuses décisions. C’est pour cela que dans certaines situations, nous avons des réactions qui nous surprennent nous-même et où nous disons : « mais pourquoi ai-je dit cela ? ».

Le problème que nous avons à résoudre est à qui nous déléguons la programmation de l’ordinateur. A l’humain ou au chimpanzé ?

Une fois le modèle introduit, le reste de l’ouvrage propose d’étudier comment gérer notre chimpanzé et reprogrammer notre ordinateur en utilisant notre humain.

 

La photo d’entête est de Matthew Wiebe.

OpenStack Summit Austin 2016

Le prochain sommet OpenStack se déroulera à Austin dans moins de 70 jours.

Vous pouvez dés à présent voter pour que vos sessions favorites soient inscrites sur le programme en suivant ce lien.

Pour ma part, j’ai proposé 2 sessions : la première parlera de ce que la science du bonheur peut apporter dans la transformation d’OpenStack et pour la seconde, nous proposons avec Mark McLoughlin d’étudier comment les organisations peuvent améliorer l’impact de leurs contributions en s’inspirant des pratiques, principes et valeurs utilisées par des projets opensource et des projets agile.

Pour voter pour ces sessions :

La cloture du vote est planifiée au 17 février à 11:59 PST

Merci pour votre soutien !

L’anecdote du sous-marin

Je suis allé une nouvelle fois voir Jean-François Zobrist en conférence. Jean-François Zobrist en conférence, c’est toujours un peu la même chose ; il raconte ce qu’il a appris des années passées avec FAVI, j’ai déjà eu l’occasion d’en parler ici ; et c’est toujours un peu différent ; car il s’adapte au contexte et raconte ce qu’il lui semble le plus important de raconter en fonction de l’audience.

Cette conférence était organisée par les groupes Germe de Bordeaux dans les locaux de l’ISG. Invité par Germe, une émanation de l’APM, il a bien sur raconté ce qu’il avait appris à l’occasion des sessions de réflexion organisée par l’APM ou Germe.

Je vous livre ici une des anecdotes que Jean-François a raconté, tout en vous invitant bien sur à aller le voir ou le revoir en conférence, et à lire ce qu’il a écrit pour transmettre ses apprentissages.

Il racontait donc, que lors d’une session organisée par Germe, ils avaient invité un commandant de sous-marin nucléaire à leur parler de son rôle de management. La surprise est venue du fait que le commandant n’est pas supposé faire quoi que ce soit dans le fonctionnement normal du sous-marin. Il peut donc passer tout son temps dans sa cabine sans jamais être dérangé par quiconque.

Si par exemple, un sous-marin d’un pays « ennemi » venait a se promener sous le nez du sous-marin, l’équipage ne le le dérangerait pas et saurait parfaitement gérer cette situation prévue. Il pourrait être dérangé si par exemple un banc de poissons ressemblait trop à un banc de poissons d’après les instruments du bord.

Cette anecdote montre l’importance de contribuer à mettre en œuvre un système (individu, équipe, organisation, méthodes…etc…) fonctionnant correctement et à laisser ce système fonctionner, tout en tendant l’oreille aux signaux faibles qui seront la source des actions d’aujourd’hui et des innovations de demain.

Il explique ainsi que c’est en écoutant un chirurgien expliquer que la difficulté des opérations du cœur était aussi liée à leur durée, et donc à la réapparition des microbes. Favi s’est penché sur cette difficulté et a développé des alliages antimicrobiens.

 

L’image d’entête est le « Typhoon3 » by Bellona Foundation. Licensed under Copyrighted free use via Commons.

What’s Next ?

Cette nouvelle édition de notre club de lecture de Bordeaux était consacrée au livre What’s Next ? de Nicolas Minvielle et Mathieu Griffoul.

2016-01-16 10.53.26

Les participants ont apprécié la facilité de lecture de l’ouvrage et son côté vulgarisateur. Il est possible de réutiliser les explications bien faites pour expliquer les idées et les outils abordés dans ce livre à des néophytes.

Comme l’on dit certains des participants, ce livre présente nos outils du quotidien, on aurait pu (on aurait dû) l’écrire.

Il est malheureusement trop superficiel, regroupe du contenu déjà vu ailleurs, sans approfondir… et plus grave… sans citer les sources…

Pour le créateur d’entreprise, ou pour le manager, ce livre peut-être un bon début pour avoir une vue des outils possibles, et pour entrer dans un état d’esprit où l’on mène des expériences pour vérifier des hypothèses, et où l’on collabore avec d’autres personnes d’horizons différents.

Une fois de plus nous regrettons que les éditions papiers et numériques ne soit pas associées, il est agréable de lire le livre papier et de s’y référer, mais les versions numériques son imbattables lorsqu’il s’agit de faire une recherche rapidement.

Nos discussions ont dépassée le cadre du livre, comme lorsque nous avons évoqué l’usage des 5 pourquoi, ce qui a débouché sur cet article de Fabrice.

Vous pouvez dès aujourd’hui proposer et choisir en votant, quel va être le prochain livre du club en allant sur notre tableau Trello. Pour y avoir accès, demandez à Isabel, Fabrice ou moi-même via Twitter.

Et bien sur vous pouvez vous inscrire sur le meetup Agile Bordeaux (dont nous sommes les organisateurs) et en profiter pour regarder les autres activités proposées.

Les autres éditions du club de lecture ont été consacrées à :

 

Agile Bordeaux

Le premier meetup Agile Bordeaux s’est déroulé hier, mardi 12 janvier, au Bac à Sable, un nouvel espace de coworking à Bordeaux

Après un mot de bienvenue de Xabina Carreau qui nous accueillait dans ce lieu très agréable. Nous avons enchainé rapidement en présentant les prochains rendez-vous du groupe :

Nous avons ensuite élargi à d’autres événements pouvant intéresser les participants, comme Agile Open France, la semaine prochaine et le meetup Lean Startup Bordeaux le 28 janvier.

Suivant une tradition maintenant bien établie, nous avons ouvert par la session de présentation en 5 minutes, pour laquelle j’avais préparé un « agile en 5 minutes ». Merci pour la vidéo Isabel 🙂

Le groupe s’est ensuite réparti sur 2 activités en parallèle :

2016-01-12 18.20.12La scierie à pratique par Chris Deniaud

3 équipes ont échangées autour des pratiques agiles grâce à cet atelier créé par Pablo Pernot et Stéphane Langlois en s’essayant à une approche de recherche de consentement. Et ils ont tous terminés en choisissant la rétrospective comme pratique qu’ils garderaient (le jeu est bien sûr sur le wiki Agile Games France).

2016-01-12 18.36.33No Scrum, No Win? par Olivier Picaud et Olivier Patou

C’était une session de rattrapage pour ceux qui auraient voulu la suivre mais n’ont pas pu…lors de l’Agile Tour Bordeaux 2015 – Scrum est simple à comprendre et difficile à comprendre. Nous sommes à la recherche d’un Mindset agile afin de traquer nos anti-patterns agile/scrum.

Nous avons ensuite continué la discussion autour d’un verre de vin. J’avais oublié de l’annoncer, mais suffisamment de participants ont pensé à amener le nécessaire ! Bravo et Merci !

2016-01-12 20.29.22Un bel évènement apprécié par les participants comme le laisse entendre le graphique Fun / Valeur 🙂

Vous pouvez bien sur contribuer au programme du prochain meetup qui aura lieu le 29 mars directement dans ce document.

DATFlock2015, licornes, équipes distribuées et mauvais agile

J’étais à Berlin pour 2 jours pour participer à #DATFlock2015 la conférence pour discuter, apprendre, partager autour des équipes agiles distribuées.

Le programme était un mélange de sessions open space et d’ateliers préparés à l’avance.

OKR, Retours et Récompenses

2 sessions m’ont été particulièrement utiles :

  • How to use OKR?
  • Fearless feedback and fair reward

Deux sessions proposées par Petra Liesmons et Kitty Iding, que je remercie au passage ! Les sujets et l’approche retenue pour les couvrir confirment le travail que je mène actuellement pour implémenter ces idées avec certaines équipes.

De la session OKR, je retiens :

  • Quelques améliorations dans la façon d’expliquer les OKR, spécialement la différence entre résultats clés et actions. C’est un aspect important, car les personnes tendent à proposer des résultats clés qui sont en réalités des actions, pour de pas si bonnes raisons. Par exemple : parce que le travail est fait aujourd’hui, parce que c’est important mais pas connecté à un OKR existant… Ce dernier point devrait être un bon signal, soit pour arrêter de faire cette action, soit pour reconsidérer les OKR définis précédemment.
  • Un autre point important, qui est souvent sujet à discussion est que les OKRs ne se cascadent pas depuis ceux de l’entreprise jusqu’à ceux de l’équipe. Il y a des objectifs et résultats clés au niveau de l’entreprise. Ils vont servir aux équipes à prendre leurs décisions et à définir leurs objectifs et résultats clés. Une équipe pouvant contribuer à tout ou partie des objectifs et résultats clés de l’entreprise
  • Les résultats clés doivent être difficiles mais pas impossibles. Ils montrent l’ambition que l’on a. Ce qui signifie que l’on doit changer l’habitude de vouloir atteindre les objectif à 100%. Une habitude qui tend à réduire l’ambition pour être sur de dépasser l’objectif.
  • Un comportement d’autant plus vrai si les objectifs sont associés à la rétribution. Donc les OKR ne doivent pas être connectés aux récompenses.
  • Les résultats clés représentent le succès, l’impact, le comportement que l’on veut induire dans l’entreprise.
  • Les OKR ne sont pas une approche venant de la direction de l’entreprise vers les employés. C’est une approche devant impliquer tout le monde dans la définition et l’évaluation, suivant une périodicité définie. Par exemple : chaque année pour la définition des OKR de l’entreprise, chaque trimestre pour reconsidérer ceux de l’équipe, et sur une base hebdomadaire pour l’évaluation par chaque équipe.
  • Les OKR sont publics dans l’entreprise, et un temps doit être consacré à l’alignement des OKR entre les équipes.
  • Il est probablement nécessaire d’avoir des indicateurs permettant d’identifier les effets de bords générés par les OKR sur les équipes, l’index de bonheur des équipiers peut-être un de ceux là.

 

2015-11-20 12.49.57De la session sur les retours et récompenses, je retiens :

  • Pour recevoir des retours clairs de la part de l’équipe, il est nécessaire de clarifier les attendus, et donc de définir les rôles en fonction de l’organisation de l’entreprise.
  • Un modèle que l’on peut utiliser pour définir les rôles et responsabilités peut être le modèle de Matti Klasson.
  • L’organisation d’un World Cafe pour définir les différents rôles de l’équipe semble être la façon la plus efficace d’y parvenir. Je vais devoir trouver un moyen d’organiser cela en ligne.
  • L’introduction aux types de personnalités (avec des outils tels qu’Insights, Ensize ou MBTI…) peut être une façon de faire prendre conscience aux personnes qu’elles doivent adapter leur façon de donner du feedback aux personnes à qui ils sont destinés.
  • Une suggestion pour aider les personnes à prendre en compte les feedbacks qu’elles reçoivent est de leur attribuer un coach personnel. Le coach personnel est un volontaire des équipes qui va pouvoir coacher 4 à 5 personnes. Ces coachs seront formés et coachés et formeront une équipe virtuelle de coachs.
  • La partie récompense de la discussion a introduit l’idée de l’évaluation pair à pair, en face à face, de chaque personne en fonction des rôles qu’elle tient. Le coach personnel aidant la personne à étudier ces scores. La personne évaluée est alors seule responsable de définir ces scores. Le manager a accès à tous les scores. Les personnes sont classées en fonction de leur score par rapport au(x) rôle(s) qu’elles tiennent. Ce classement est comparé au classement des rémunérations par rapport au rôle et une adaptation est proposée si nécessaire.

Organisation et Architecture

communication-overheadJ’ai également apprécié la conférence d’ouverture du deuxième jour donnée par Johannes Mainusch. Et particulièrement la façon de montrer la connexion entre la taille de l’équipe, le nombre de relations à maintenir et par conséquence le décroissement de la production de travail possible lorsque on ajoute trop de monde à l’équipe.

La conclusion de l’intervenant était qu’il souhaite des équipes pas trop petite, pour pouvoir faire de la programmation en binôme, et pour pouvoir former de nouvelles équipes par division cellulaires.

L’idée d’avoir des architectes faisant parti de chaque équipe et travaillant ensemble à rendre l’architecture évolutive et à s’assurer que les équipes pluridisciplinaires peuvent être indépendantes.

ElmoEt bien sur, je vais utilisé la technique de facilitation ELMO, qui peut fonctionner avec une équipe distribuée en vidéo conférence. Chaque personne a un papier, il peut y avoir un dessin d’Elmo, et lorsque la conversation traine en longueur, les membres de l’équipe peuvent tendre leur papier pour signifier que l’on doit passer à autre chose. ELMO veut dire Enough Lets Move On.

Un fishbowl (bocal à poisson) a été organisé lors du deuxième jour, et pour lancer la discussion Lisette Sutherland a expliqué pourquoi elle avait invité Yegor Bugayenko, fondateur et directeur technique de Teamed.io. Yegor travaille avec des personnes distribuées à travers le monde, et dit que les activités de team building sont sans intérêts. Qu’il s’agit juste d’un signe de mauvais management essayant de corrompre les personne pour remplacer la discipline par l’amitié.

Il était très intéressant d’avoir un point de vue contradictoire et respectueux dans la conférence. Yegor a expliqué sur son blog l’expérience qu’il a tenté avec les participants de son atelier.

Les idées maitresses : les clients veulent le logiciel et ne sont pas intéressés par l’équipe, et une équipe est moins efficace que des individus bien orchestrés. J’ai un désaccord principal… Mais nous y reviendrons…

Comment le système de Yegor fonctionne-t-il ?

Les projets sont découpés en milliers de tâches de 30 minutes chacune. La tâche est proposée à des développeurs qui peuvent prendre ou laisser. Ils seront payés à la tâche uniquement si ils livrent avec le niveau de qualité escompté. Ils devront garder à l’esprit qu’il s’agit de tâches d’une demi-heure, et donc si par exemple, ils ne comprennent pas la classe qu’ils doivent utiliser en un coup d’œil, c’est qu’elle n’est pas bonne et nécessite d’être refactorée. Et donc, ils doivent créer une nouvelle tâche explicitant ce dont ils ont besoin et mettre la tâche initiale en pause. Une autre personne, avec un rôle d’architecte, elle aussi payée à la tâche, validera si la tâche est réellement nécessaire.

Les risques sont gérés par le nombre. Ils choisissent de mettre 25 développeurs sur un projet qui pourrait en nécessiter 3. Si l’un d’eux échoue à délivrer une tâche d’une demi-heure (petit risque), la tâche sera réassignée à quelqu’un d’autre.

Personnes distribuées et pas équipes distribuées

Ce système ne peut probablement pas fonctionner pour tous. Yegor affirme que beaucoup de personnes veulent travailler avec eux, ils ont donc l’opportunité de choisir. Ils donnent du travail à tout les candidats, au départ sur des projets open source pour évaluer leur comportement, si cela se passe bien, ils se verront attribuer des tâches de projets clients. Si je me souviens correctement des données, 1 sur 20 candidats va rester.

Licornes

Durant le fishbowl, une personne s’est assis sur la chaise vide et a expliqué que les licornes de la silicon valley (des startups avec une valorisation de plus d’1 milliard de dollars) démontraient la validité du modèle d’équipe pluridisciplinaire… La réponse de Yegor a été que 1 ou même 100 exemples de ce type ne suffisait pas pour démontrer le rapport de cause à effet… Combien d’équipe font la même chose sans pour autant parvenir à ces résultats exceptionnels ? C’est un bon point bien sur, nous avons une tendance à interpréter hâtivement des situations en fonction de nos propres croyances…

Désaccord, Créativité et Innovation

Le principal désaccord que j’ai concerne la créativité et l’innovation. Les équipes pluridisciplinaires permettent à différents types de personne de travailler ensemble avec un but partagé. Et des frictions qui naissent de ces différences lors de la collaboration émergent de nouvelles idées géniales. Les pratiques agiles sont conçues pour permettre ces opportunités.

Mauvais Agile

Le problème est qu’avec les mauvaises implémentations des pratiques agiles. Ces équipes qui disent faire de l’agile mais pour qui :

  • Pas de collaboration dans l’équipe (Une story assignée par personne par exemple)
  • Pas de discussion avec le product owner
  • Des Story qui ressemble à des tâches dont on ne connait pas le but
  • Pas de revues avec les clients
  • Pas de découpage des tâches en équipe (ce qui devrait faire émerger des nouvelles idées et des architectures évolutives plus pertinentes)
  • Pas de programmation en binome
  • Revue par un architecte
  • Tests par une équipe d’assurance qualité en dehors de l’équipe

Si l’on combine ces mauvaises pratiques avec un mauvais management, qui ne sait pas ce qui doit être fait, qui change les priorités chaque jour, fixant des objectifs irréalistes etc…

On en vient à cette question de savoir comment implémenter une organisation efficiente pour développer des logiciels et des alertes pour les implémentations partielles sans compréhension des conséquences de certains choix.

 

Un grand merci à Lisette, Lucius et tous les autres contributeurs de cet excellent événement.

Revue annuelle de performance

Lorsque je présente les 14 points de Deming et les 7 maladies mortelles des organisations, j’ai pris l’habitude d’utiliser certains principes et maladies en fonction du contexte pour donner l’envie aux personnes de creuser un peu plus.

Une des maladies mortelles que j’utilise régulièrement est la troisième :

Évaluation à l’efficacité, au mérite, ou par des entretiens annuels.

La réaction des personnes était habituellement similaire. Ils étaient d’accord que c’était un problème qu’ils avaient, que c’était inéfficace et source de démotivation… Mais ils étaient « obligés » de se soumettre aux règles en place dans leur organisation.

Entendons-nous bien, ces règles ont été mises en place avec une intention initiale de développement des personnes et d’amélioration de la performance de l’organisation. Donc l’intention est bonne, le seul problème est l’évaluation de la performance de la solution retenue, et sa (non) remise en cause.

Depuis cet été et la médiatisation de la fin des entretiens annuels chez Accenture, dans le Washington Post, le Financial Times entre autres. Accenture a rejoins les autres entreprises ayant abandonnées cette pratique, comme Deloitte avant eux par exemple, ayant travaillées à simplifier radicalement la façon d’envisager les choses.

C’est donc une bonne opportunité pour initier un changement de modèle dans les entreprises qui utilisent encore cela. Une opportunité de repartir en redéfinissant l’intention. Que veut-on accomplir ? Développement des personnes ? Amélioration de la performance de l’organisation ? Autre chose ?