Le média du Worklab 
Software for your head : c’est ce quoi ce livre ?
Jim et Michèle Mc Carthy ont mené une drôle d’expérience. Ils ont étudié pendant 2 ans le fonctionnement de plus de 60 équipes. Chaque équipe avait 5 jours et 5 nuits pour :
- Former l’équipe
- Partager la vision du produit
- Se mettre d’accord sur la façon de fabriquer le produit
- Concevoir et fabriquer le produit
De cette observation, ils ont tiré une sorte de manuel de l’équipe idéale. Ainsi, ils ont organisé ce manuel selon les parties suivantes :
- Les patterns (ça va parler à ceux qui font de l’architecture logicielle) : ce qu’il faut faire, les positions à adopter pour que l’équipe fonctionne au mieux dans une situation donnée
- Les antipatterns : ce qu’il ne faut pas faire ou les fausses solutions.
- Les protocols : procédure à suivre dans certains moments clés de la vie d’une équipe (partager une vision, décider…)
Précisons quand même qu’il s’agissait d’équipes de développement logiciel. Je vous livre ici ce que j’en ai retenu du livre : Software for you head. Cette synthèse est loin d’être exhaustive (le livre fait presque 450 pages en anglais s’il vous plaît !!!)
« Check in protocol »
Partant du principe que dans une équipe la plus grande distance à surmonter c’est la distance psychologique entre les personnes. On retrouve ici les éléments qui permettent de réduire cette distance.
- Dans un groupe, à tour de rôle chacun dit « je me sens inquiet et/ou en colère et/ou content et/ou effrayé ». Éventuellement, on pourra expliquer brièvement les raisons de son état émotionnel. Les participants peuvent toujours passer leur tour s’ils le souhaitent.
- Dire « j’y suis » pour affirmer que vous êtes pleinement présent et engagé dans ce que vous faites.
- Le groupe répond « bienvenue » pour indiquer qu’il a entendu le Check in et qu’il accepte l’engagement.
Exemple : je me sens inquiet, heureux et triste. Inquiet que ce nouveau projet ne soit pas intéressant ou tourne mal. Heureux que nous commencions un nouveau projet. Je me sens aussi triste parce que je ne suis pas avec ma famille aujourd’hui.
Il faut se limiter à ces 4 états émotionnels (en colère, inquiet, triste, heureux). Même s’il existe une multitude de façons d’exprimer ses sentiments, on reste relativement fidèle en combinant ces 4 états. Se limiter à ces 4 états permet également de réduire l’ambiguïté, de simplifier le process et d’éviter de se réfugier dans des expressions un peu fourre tout.
Aucune discussion n’est autorisée pendant le Check in. Par ailleurs, il est important de ne pas rendre les autres fautifs pour les émotions que vous ressentez.
Qu’est-ce que ça apporte ?
- L’engagement de l’équipe
- On réduit les incompréhensions
- On augmente l’attention des membres de l’équipe (ce qui s’explique par le fait que chacun se livre un peu)
- On développe la maturité de l’équipe en acceptant la réalité des relations humaines
- On aide les membres de l’équipe à mieux se comprendre
Quand l’utiliser ?
- En début de réunion
- Quand des comportements non constructifs commencent à apparaître
- Quand vous en ressentez le besoin
« Decider protocol »
Vous l’avez compris, il s’agit ici de prises de décisions. Globalement pour les auteurs, il existe 2 grandes familles de méthodes pour prendre des décisions.
- La famille des décisions plutôt démocratiques, sécurisantes et basées sur le consensus
- La famille des décisions autocratiques : une personne décide parce qu’une entreprise, ça n’est pas une démocratie et puis c’est tout
On retrouve ici une approche alternative plutôt intéressante (qui se rapproche pour ceux qui connaissent du consentement en sociocratie)
- Un participant exprime une idée, et une seule, de façon concise et claire en disant « je propose … »
- Il compte 1,2,3
- Chaque membre de l’équipe vote simultanément :
- En levant le pouce pour signifier oui
- En baissant le pouce pour signifier non
- Avec le plat de la main pour indiquer qu’il soutient cette proposition sans être complètement d’accord, ce qui correspond à un oui avec réserve
S’il y a une trop grande proportion de non et de oui avec réserve (environ 30% des participants), alors on oublie cette proposition. Si un des participants ayant voté non précise que son non est catégorique et sans appel alors la proposition est également rejetée (dans les faits on se rend compte qu’il y a rarement de non catégorique). S’il y a uniquement quelques non parmi les votants, alors on utilisera le « Resolution protocol » (voir plus bas). Dans tous les autres cas la proposition est acceptée.
« Resolution protocol »
Dans le cas où seulement quelques participants ne sont pas d’accord :
- Celui qui a fait la proposition demande à tous ceux qui ont voté non : ce qu’il leur manquerait pour qu’ils votent oui ?
- Chaque votant ayant voté non s’exprime avec une phrase courte et précise
- L’auteur de la proposition fait alors une offre :
- S’il s’agit d’un aménagement mineur : on ne refait pas voter l’ensemble des participants
- Si l’aménagement est plus conséquent alors on refera voter tous les participants
- Les personnes ayant voté oui ou oui avec réserve ne sont pas autorisées à s’exprimer
- Si les opposants changent alors leur non en oui ou en oui avec réserve, alors la proposition est acceptée
« Shared vision protocol »
Ou comment partager une vision dans une équipe :
- Définir la metavision c’est à dire
- Qu’est-ce qu’une vision ?
- Comment la réaliser ?
- Définir la vision à long terme en se posant 2 questions :
- Comment sera le monde quand nous aurons fini notre travail ?
- Comment sera la vie de nos clients ? (Pour se fixer les idées, on pourra choisir une échéance à 20 ans. Cette vision doit être imaginative, mesurable et s’exprimer en quelques mots)
- Définir la vision de la version du produit à construire. Il s’agit d’une première étape de la vision long terme.
Voici quelques exemples de visions long terme / version :
Vision long terme : un homme qui marche sur la lune
Version 1 : orbite autour de la terre
Vision long terme : un ordinateur sur chaque bureau
Version 1 : des logiciels faciles à utiliser
« Perfection game protocol »
C’est une bonne méthode pour obtenir du Feed back tout en restant constructif et positif :
- Les participants se positionnent en cercle
- Chaque participant énonce une tâche simple qu’il peut réaliser durant le jeu. Par exemple : claquer des doigts, siffler…
- Le premier joueur réalise sa tâche
- Les autres joueurs notent la performance de 1 à 10. 10 signifiant que la performance était parfaite.
- Chacun explicite d’abord ce qu’il a apprécié et ce qu’il faudrait faire pour qu’il donne 10
En vrac, quelques idées fortes :
- Toujours donner sa chance au produit et ne pas juger une idée avant de l’avoir vraiment comprise.
- L’équipe = le produit. C’est une façon d’appréhender les choses sous un angle original. L’idée est que le produit que réalise l’équipe sera à l’image de l’équipe. Si l’équipe est brillante, le produit (ici le logiciel) sera séduisant et efficace. Si l’équipe est procédurière, votre logiciel péchera par un excès d’architecture. Ça se tient!
- L’écologie des idées
- L’équipe ne doit pas qualifier l’importance d’une idée en fonction de la personne à l’origine de cette idée
- L’équipe doit produire un maximum d’idées puis sélectionner la plus pertinente
- L’équipe doit mettre en œuvre uniquement la meilleure idée
- L’équipe doit créer un environnement propice à l’expression des idées
- Si quelqu’un ne demande pas de l’aide, elle ne l’acceptera pas si on lui offre
Conclusion
Un livre très riche dont je ne livre ici qu’un très court aperçu. J’ai volontairement omis quelques idées que je ne partage pas vraiment, comme le fait de sortir les équipiers qui ne seraient pas suffisamment efficaces (je trouve ça dur et pas toujours possible).
On y retrouve des idées et des points de vue proches de la philosophie de l’agilité.
Le site des auteurs : http://www.mccarthyshow.com/
Acheter le livre :
Par Sacha Lopez
