I am still standing

Il y a quelque temps, j’ai ajouté une carte dans la colonne arrivée de mon tableau kanban personel (je peux partager le modèle si nécessaire). La carte était labellisée « Standing Desk » (bureau assis/debout).

Lors de la revue de mon tableau, j’ai déplacé cette carte dans la colonne « Un jour peut-être ». Et la carte est restée là…

Plus tard au cours de la même semaine, plusieurs facteurs m’ont amenés à considérer à nouveau cette carte :

  • J’avais sauté plusieurs pauses sur plusieurs jours et oublié de changer régulièrement de posture, et donc mon dos commençais à me faire mal
  • Des collègues discutaient de l’idée d’acquérir des bureaux assis / debout et ils l’ont fait et racontaient ensuite qu’ils étaient ravis 🙂 (Thank you Mark and Hugh!)

bekant-desk-sit-stand-white__0384121_PH125329_S4

J’ai donc déplacé la carte dans la colonne « à faire cette semaine », étudié les différentes options et décidé de changer mon bureau (j’avais acheté le précédent 20 ans avant) en optant pour le modèle Berkan de IKEA.

Avec ce bureau, je peux avoir toute mon installation qui bouge. La première semaine, j’ai vraiment pensé que cela allait m’aider à ne plus oublier les pauses et les changements de posture. J’avais en effet du mal à rester debout très longtemps et j’alternais donc les positions assis et debout au cours de la journée.

2016-03-22 07.29.17 2016-03-22 07.30.03Après 2 semaines, je peux rester debout plus longtemps, le chat utilse ma chaise, et je dois donc m’assurer de bien démarrer mon minuteur pomodoro pour me souvenir de faire des pauses et de changer de posture. Le fait d’être debout a des aspects positifs sur les nombreuses conférences vidéos que j’ai au cours de la journée : je suis capable de fermer les appels plus vite. Le même effet qui a conduit à décider que les synchronisations quotidiennes devaient se faire en étant debout (Il y a une étude la dessus).

Je vous recommande de tester, et vous allez probablement adopter !

 

Le jour ou j’ai reçu mon bureau IKEA, Lisette Sutherland a publié un article montrant son bureau, probablement le même modèle dans une autre taille ! D’ailleurs, si vous êtes intéressé par la collaboration et le travail à distance vous pouvez la suivre !

 

La photo d’entête est de Ryan McGuire.

Laissez nous coder !

Cet article est en travaux depuis longtemps. Une remarque d’une personne avec qui je travaille m’a rappelé l’urgence de contribuer à résoudre ce problème. Il a dit :

Arrêtez de nous interrompre ! Laissez nous coder !

J’ai commencé à être très sensible aux interruptions avec la découverte de la technique Pomodoro que je raconte dans cet autre article.

Ce que j’ai pu expérimenter est que, lorsque j’étais capable de me focaliser sur une chose, j’étais extrêmement efficace. J’ai donc essayé d’inciter les personnes des équipes avec qui je travaillais à respecter des périodes de la journée sans interruption.

Les personnes identifient facilement les autres comme étant source d’interruption. C’est généralement la partie la plus facile à couvrir et en réfléchissant en équipe on peut trouver des accords dans l’équipe pour stopper le flux d’interruptions et ainsi juguler les effets négatifs.

Il est plus délicat d’admettre que nous sommes nous-mêmes notre propre source d’interruption. Nous commençons quelque chose, et nous voyons une notification d’une autre application, ou notre esprit vagabonde et nous emmène sur autre chose, etc… Il faut donc un fort engagement personnel pour résister à ces multiples tentations de quitter ce que l’on est en train de faire.

Le problème est encore plus important lorsque l’équipe est distribuée.

En effet, avec des équipes co-localisées, j’avais pu expérimenter 2 stratégies :

  • La première était un symbole sur le bureau indiquant que la personne ne souhaitait pas être interrompue (une mascotte rigolote généralement) qui était comprise par les autres personnes de l’équipe
  • La deuxième était la synchronisation de l’équipe sur un rythme : 50 minutes de travail sans interruption, 10 minutes de pause, 15 minutes dédiées aux interruptions, et on recommence avec une pause allongée au moment du déjeuner.

La synchronisation était la technique la plus efficace, mais c’était aussi la plus exigeante en terme de discipline des membres de l’équipe.

Avec une équipe distribuée, la connexion se fait grâce au moyen de communication électronique, et il y a rapidement une exigence tacite qui veut que l’on se doit de répondre rapidement aux sollicitations par email, et encore plus rapidement aux sollicitations sur les salles de discussions (irc, jabber, slack ou autre).

Et si l’on accepte cela, on va passer des journées à sauter d’un sujet à l’autre sans jamais vraiment pouvoir accomplir quelque chose.

LarryKim-MultitaskingCette illustration issue de l’article de Larry Kim sur les tâches en parallèle explique bien cela.

Notre satisfaction va souffrir de ces changements de contexte incessant. De plus chaque fois que nous allons revenir sur une tâche, il est probable que nous allons perdre beaucoup de temps à retrouver le niveau de compréhension du problème que nous cherchons à résoudre.

MikeCohn-ContextSwitchingDans son livre Succeeding With Agile, Mike Cohn cite l’étude de Kim Clark et Steven Wheelwright sur l’impact du multitasking sur la productivité, dont les résultats sont visibles sur l’illustration extraite du livre.

Si l’on est dans une organisation où le travail est distribué par des managers et que ceux-ci transmettent cette pression de l’instantanéité, le temps gâché par les demandes incessantes va pratiquement paralyser l’intégralité de l’organisation. C’est ce qui conduit certaines grandes organisations à s’interroger sur la possibilité qu’une petite équipe de moins de 10 personnes puisse accomplir plus que leur équipe de 300 personnes.

Ce phénomène sera moins marqué dans une organisation où le travail est distribué par le système lui-même et où chaque membre de l’équipe sait ce qu’il doit prendre à la suite d’une tâche réalisée.

group-chat

De façon amusante, Jason Fried a publié un article sur Medium alors que j’écrivais celui-ci. Il fait une série de propositions pour changer l’agrément de l’équipe à propos des moyens de communication et de leurs usages qui me paraissent importants.

La recommandation que je ferais est de prendre un temps pour définir avec l’équipe :

  • l’usage des moyens de communication : ce qui sera discuté par email, par messagerie instantanée privée ou de groupe, par le biais de documents partagés qui permettent une meilleure construction d’une position commune à l’équipe, en veillant à définir les délais de réaction adaptée à chaque cas
  • la façon de protéger chaque personne des interruptions : soit en acceptant des périodes d’indisponibilité, soit en synchronisant l’équipe (plus délicat lorsque l’on est sur distribué sur plusieurs zones géographique), soit en dédiant des personnes sur une période définie à gérer les interruptions inévitables
  • de jouer à un jeu pour comprendre la puissance de la focalisation (comme le jeu du prénom)

Et vous comment laissez vous « coder » les personnes qui travaillent avec vous ?

 

La photo d’entête est de Ryan McGuire.

 

 

LessPass – la gestion des mots de passe

LessPass est une solution de gestion des mots de passe reposant sur une idée complètement différente de celles aujourd’hui existantes.

La plupart des solutions reposent sur l’idée d’un stockage centralisé de l’ensemble des mots de passe protégé par un mot de passe maître. Ce stockage centralisé peut être artisanal, comme un fichier de type tableur stocké sur sa propre machine ou sur un serveur. Ou il peut être un peu plus élaboré comme les solutions proposées actuellement pour mémoriser tous vos mots de passe.

LessPass est différent dans le sens ou il ne mémorise aucun de vos mots de passe. Le système va simplement les créer à nouveau lorsque vous en avez besoin sur la base des informations que vous fournirez. Cela ne nécessite donc pas de faire confiance à un tiers.

Bien sur, le projet est open source, afin que le code puisse être audité. Et, Il n’y a aucun tracker sur le site, ce que vous pourrez vérifier avec Privacy Badger par exemple.

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.

Joyeuse Année !

Je souhaite que cette nouvelle année vous remplisse de joie. Et que vous ayez l’opportunité d’apporter de la joie autour de vous.

Cette belle photo de David Hermans exprime bien cela.

2016-David-Hermans-Joie

Collaboration pair à pair à grande échelle

Un ami m’a demandé de répondre à 2 questions à propos de la collaboration dans les projets open source pour l’aider sur un de ces projets.

Je me demandais quelles pouvaient être les questions qui n’avaient pas déjà été répondues des millers de fois. Cette curiosité m’a conduit à une conversation captivante, et des idées intéressantes que je voudrais partager avec vous.

Première question : Quelle est la chose la plus difficile à propos des rétributions et récompenses pour soutenir la communauté contribuant à un projet open source ?

Il y a de nombreux facteurs de motivations et récompenses que l’on peut trouver à contribuer à un projet open source. La première peut être le produit / service auquel vous contribuez. La motivation et satisfaction de contribuer à un objectif plus grand que soi. La collaboration avec d’autres qui va améliorer la qualité et la sécurité du produit.

Il y a aussi les nombreuses opportunités d’apprentissage. Parce que le code est public (dans le cas du développement logiciel) et donc vous pouvez apprendre comment les autres résolvent les problèmes en inspectant leur code, et vous pouvez également apprendre des inspections des autres. De plus, cela peut conduire à détecter des opportunités d’emplois intéressantes.

Certains vont travailler dur pour augmenter leur réputation, pour gagner le statut ou l’autorité sur un projet.

Et donc, la chose la plus dure sur ce sujet des récompenses pourrait être de comprendre les motivations des contributeurs et d’adapter les récompenses à ces motivations.

Seconde question : Quelle est la chose la plus difficile à propos des prises de décision dans un projet open source ?

La question au sujet des décisions est intéressante et difficile. Certains mécanismes à l’œuvre dans les projets sont très collaboratifs et l’on peut dire que les meilleures idées gagnent. Mais parfois, les décisions basées sur l’autorité  acquise par le passé, peuvent parfois être mauvaises, et même totalement guidées par l’égo.

Les organisations de certains projets open source sont assez traditionnelles et hiérarchiques avec des conseils d’administration, des comités techniques, et une hiérarchie au sein des sous-projets. Même si les personnes sont co-optées ou élues par leurs pairs pour gagner autorité et statut. C’est toujours une structure hiérarchique.

Ces organisations émergent parce que nous avons une défaillance humaine qui nous conduit à mal comprendre les processus de décisions. Nous recherchons quelqu’un qui va ultimement « prendre » la décision.

Dans certaines organisations où il n’y a pas de mécanisme d’arbitrage en place, où personne ne peut décider ultimement, les personnes tendent à devenir plus raisonnables et commencent à construire des décisions et évitent de laisser leurs ego saper l’effort collectif. Ces personnes ont appris comment faire advenir cela.

Après une assez longue conversation autour des mécanismes de décision et des organisations. Nous sommes revenus à la première question… J’avais (intentionnellement) oublié de parler de l’argent et du partage de la valeur créée, car je n’ai pas vraiment de solution à proposer qui me satisfasse… Les personnes qui contribuent à des projets open source sont souvent employées par des entreprises qui ont besoin du produit / service, et lorsqu’elles ne le sont pas, elles sont parfois en recherche d’opportunité d’emploi… Pour d’autres, ils ont une autre source de revenu et sont satisfaits par les autres récompenses.

C’est le moment où mon ami m’a expliqué leurs idées pour résoudre le problème des récompenses et de la distribution des décisions évitant les mécanismes de concentration du pouvoir dans un centre.

Ils veulent utiliser la puissance de la technologie blockchain popularisée par l’expérience bitcoin. Je dis expérience car le bitcoin est une façon de démontrer ce que l’on peut faire avec cette technologie.

Cette courte vidéo donne un aperçu de ce qu’est le blockchain :

Si l’on utilise la technologie blockchain pour créer des services distribués, on peut créer un service de covoiturage sans centre, comme LaZooz. Ainsi les personnes qui partagent les biens et les services le font au bénéfice de la communauté sans avoir à servir les intérêts d’une entreprise classique comme uber, airbnb, blablacar…

On peut imaginer d’utiliser la technologie blockchain pour faciliter la construction des décisions dans un projet open source et de récompenser les contributeurs en fonction de la valeur de leur contribution et du risque qu’ils prennent lorsqu’ils rejoignent un projet très tôt par exemple. Plus sur ces idées en regardant http://backfeed.cc/ and https://www.ethereum.org/

Quelques leçons (ré)apprises :

  • Ne dites pas aux personnes, demandez leur. Si vous voulez que des personnes s’intéressent à votre idée, c’est probablement une bonne idée de leur poser quelques questions qui vont les aider à prendre conscience du problème que vous essayez de résoudre.
  • Accroitre la prise de conscience sur les différentes motivations et les différences entre les personnes est une partie importante lorsque l’on commence à travailler avec une équipe. Je vais réutiliser rapidement le tableau Trello qui me permet d’utiliser les moving motivators avec des équipes distribuées.
  • Ouvrez vous aux autres et à leurs idées…

Commentez et partagez cet article si vous avez apprécié la lecture 🙂

 

La photo d’entête est de Tim Swaan

Exercices d’écoute

J’ai utilisé, une fois de plus, des exercices d’écoute lors de la masterclass DevOps que j’ai donné avec un de mes collègues à Ho-Chi-Minh-Ville lors du Red Hat Tech Exchange. Je me suis engagé cette fois à publier une courte description de ces exercices.

Pour commencer, je prépare le groupe avec 1-2-3-Go, un petit exercice d’échauffement qui permet de comprendre que nous n’utilisons probablement que nos oreilles dans le processus d’écoute 🙂

Je demande ensuite au groupe de former des paires.

Première règle

Je leur explique que nous allons commencer avec une personne en écoute et une personne qui parle et que nous aurons l’occasion d’échanger les rôles ensuite.
Ceux qui parlent vont pendant 60 secondes raconter une histoire sur un sujet très important pour eux.
Ceux qui écoutent devront respecter la première règle : Ne pas parler.

Je facilite ensuite une session d’échange en demandant à ceux qui écoutaient comment ils ont trouver l’exercice, puis à ceux qui parlaient comment ils ressentaient l’écoute de leur partenaire. J’insiste sur leur ressentis de la durée de 60 secondes, était-ce long ou court ? Je fais ressortir le fait que poser des questions peut faire diverger ceux qui parlent de leur chemin de pensée, et que cela peut les amener vers quelque chose d’important pour vous, mais pas pour eux.

Deuxième règle

Lorsque le groupe est prêt, je leur propose d’inverser les rôles d’écoute et de parole et j’introduis la deuxième règle : Ne penser même pas à parler. Et nous recommençons pour 60 secondes d’une histoire vraiment importante pour eux.

La seconde sessions de discussions est encore plus intéressante, on parle des difficultés à ne pas laisser l’esprit vagabonder vers quelque chose d’autres. Il y a bien sur des questions sur l’importance des questions permettant de clarifier, ou qui montrent l’intérêt de ceux qui écoutent. J’essaie généralement de ne pas répondre, une partie du groupe comprenant très vite l’impact et étant en mesure de répondre directement. Quel est le but de vos questions si vous n’écoutez pas les réponses, mais que vous êtes en train de réfléchir à votre prochaine question ? Vos questions auront sans doute une réponse si vous laissez la personne finir de parler, ou elles s’avèreront de peu d’intérêt à la fin.

Variantes

Il y a de nombreuses variantes possible pour ce simple exercice :

  • Vous pouvez proposer que les personnes préparent leurs discours dans le but de se présenter. Vous devrez prévoir un peu plus de temps pour cela (probablement 90 ou 120 secondes…)
  • Vous pouvez proposer que les personnes traces une petite barre pour chaque question qu’ils ont durant la première phase, et qu’ils cochent chaque barre lorsque la question est répondue. Vous pourrez alors leur demander combien de questions restent sans réponse… et d’estimer l’importance de ces questions.
  • Vous pouvez proposer de travailler en groupe de 3 personnes avec une jouant le rôle d’observateur.

J’ai entendu parler de ces exercices par Paul Klipp à ALE2014. Une autre fois, j’ai participé à une session avec Olaf Lewitz et Michael Sahota au cours du Scrum Day à Paris en 2015. Et encore une autre fois lors d’une session donnée par Oana Juncu durant Agile France 2015. A chaque fois, il y avait des variantes, et à chaque fois c’était très puissants. J’ai eu l’occasion de l’expérimenter de nombreuses fois et cela contribue grandement à la prise de conscience de l’importance de l’écoute et un grand facilitateur des conversations qui suivent.

Qu’en allez-vous essayer ?

Photo d’entête Listen to ME! par Jonathan Powell sous licence Creative Commons