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.

 

 

Why work doesn’t happen at work

Une intervention de Jason Fried (37signals) lors de TEDxMidwest qui explique pourquoi le travail n’est pas fait au bureau.