Nemawashi, la voie du consensus

Il y a une pratique déroutante pour les occidentaux qui travaillent dans certaines entreprises japonaises, ce sont les réunions et plus particulièrement ce que l’on appelle le nemawashi : la voie du consensus.
Au premier abord, « consensus » n’est pas le mot qui peut venir à l’esprit quand on sait que ces réunions servent principalement à statuer sur des décisions qui ne sont pas discutées au cours de la réunion.

Comme consensus est un mot qui a du sens pour moi et malgré que je n’ai pas eu la chance de travailler au Japon, je vais quand même tenter d’expliquer ce qui me plait dans l’idée et tant pis pour les imprécisions ou les inexactitudes: nous sommes tous perfectibles. 🙂

La réunion n’est pas un cadre propice aux discussions.

C’est un peu provocateur, mais ça me semble factuel.

Après plusieurs heures enfermé dans un bocal avec vos collègues, même avec un facilitateur de haut vol, la tension monte toujours un peu et personne ne peut vraiment maintenir une écoute active des autres. Vous n’êtes pas totalement réceptif.

La solution est de raccourcir les réunions en ayant si nécessaire, un geôlier pour timeboxer, et alors dans ce cas là soit vous prenez les décisions difficiles avec un consensus forcé (la majorité) pour cause de temps, soit vous reportez la décision à la prochaine réunion, où le problème restera plus ou moins le même.

L’approche nippone

Si je devais la décrire en un mot, je dirai qu’elle est concentrique.
Dans une première phase on fait le tour du problème en se rapprochant du cœur petit à petit.
Cette phase peut paraitre longue, voire molle mais dès lors qu’une décision en émerge, tout s’enchaine très vite chacun fait ce qu’il a à faire, sans revenir sur le problème, sans s’opposer au mouvement. C’est ce qui perturbe les occidentaux.

Analogie avec le développement

Eh oui, en tant que développeur c’est difficile de ne pas faire l’analogie.

Vous avez besoin de faire quelque chose de particulier avec un logiciel, vous faites développer ou vous développez donc une nouvelle fonctionnalité. L’équipe de développement ne va pas le faire d’un claquement de doigts, consciencieuse, elle va faire émerger la solution par des tests qui étape par étape vont guider vers la résolution de votre problème. C’est comparable à la première phase de l’approche nippone.
La deuxième consiste simplement à utiliser votre fonctionnalité.

A quoi sert donc une réunion si les décisions sont prises en amont ?

A quoi sert la démo d’un produit ?
Je n’aime pas le terme ”valider” lorsqu’on parle d’une démo, parce qu’il a tendance à sous-entendre que l’équipe a fait de son mieux et espère que « ça va passer ».
Je préfère « confirmer » car malgré tous les efforts pour coller à un besoin on est pas à l’abri d’une erreur.
C’est aussi le but premier de la réunion, confirmer les décisions et comme pour la démo, les cas de non confirmation sont censés être rares.

Le but secondaire, c’est la cohésion.
C’est là que ça devient un peu plus difficile à digérer pour nous occidentaux certainement à cause d’une mauvaise interprétation culturelle du mot consensus, qui n’est pas synonyme de « tout le monde est d’accord et partage le même avis ».
Le consensus signifie davantage que tout le monde a pu exprimer son opinion et qu’à l’écoute de celui des autres, on concède une décision collective même si elle ne nous est pas favorable.

Si vous pensez qu’à force de harceler vos collègues vous pourrez imposer votre opinion et faire revenir l’équipe sur une décision, il y a clairement un dysfonctionnement du processus décisionnel qui vous permet d’y croire et/ou d’y parvenir.
Cette défaillance divise l’équipe et ralenti l’exécution du travail.

Imaginez maintenant le poids d’une décision exposée en réunion et adoptée non pas à la majorité mais par l’intégralité de l’assemblée (la main levée peut renforcer l’impact).
Même si la décision n’est pas la bonne, on peut toujours en prendre d’autres plus tard et s’adapter mais l’équipe pourra la tester plus facilement et aura un feedback de meilleure qualité si tout le monde se mobilise dans la même direction pour atteindre l’objectif.
C’est donc primordial de jouer le jeu même si on est pas d’accord et c’est cela à mon avis la force du nemawashi, il clarifie le processus de décision et renforce la cohésion.

capture vidéo: California Milk Processors Board
Imitation Milk, experience it now !

Tout réside dans la mise en œuvre.

C’est naturel de défendre son opinion jusqu’au bout si on a une chance que cela porte ses fruits et c’est même le signe d’un engagement profond dans ce que l’on fait.
Ce n’est donc pas tant une question de culture individuelle mais davantage une défaillance dans la gestion des prises de décisions.

Bien évidemment, cela serait trop simple et bien moins intéressant, s’il y avait une méthode générique que l’on puisse appliquer sans réfléchir pour régler ce problème.
La mise en œuvre dépend de votre équipe, de votre entreprise, de vos projets, cependant un exemple et quelques recommandations pourront peut-être s’avérer utile parce que c’est une pratique à double tranchant.

S’engager dans la voie du consensus.

A priori, il faut être en position de proposer cela à son équipe, c’est à dire avoir plutôt un rôle de facilitateur, coach ou scrum master, mais dans une équipe véritablement auto-organisée tout le monde doit pouvoir le faire du moment que vous n’êtes pas là depuis trois jours (parce que ça pourrait être une mauvaise compréhension de votre part du fonctionnement de l’équipe).

La rétrospective me parait le moment le plus adapter et pour illustrer votre proposition, ça peut être utile de relever deux ou trois cas concrets et caractéristiques du dysfonctionnement (réunions interminables, décisions contestées, absence de décision).
Une fois un ensemble de faits ou le problème explicité, c’est à l’équipe de trouver la solution, les outils et/ou les règles pour que tout le monde puisse exprimer son opinion librement sans entraver la prise de décision.
Un exemple concret peut être la mise en place d’un tableau sur lequel chacun est libre de coller des post-it avec une phrase ou deux qui soulève un point à décider. Il est possible de fixer des règles pour en limiter le nombre ou pour les hiérarchiser.
Le but de ces post-it et de fournir des sujets prétextes à la discussion et à l’harmonisation de l’équipe en groupe restreints ou non, aux moments qui semblent les plus appropriés comme par exemple lors des pauses cafés, des repas, ou de réunions informelles si nécessaire.
Chaque membre de l’équipe appose une gommette de couleur (chacun la sienne) lorsqu’il a le sentiment d’avoir pu exprimer son opinion sur un sujet ce qui permet de visualiser l’avancement du processus de décision et de se mettre à l’écoute des bonnes personnes.
Un facilitateur est responsable de synthétiser les décisions qui émergent pour les exposer lors d’une réunion rapide dont le but est leur confirmation.
Comme dans tous les groupes certains peuvent se sentir lésés malgré des règles claires, il est envisageable de changer de facilitateur à tour de rôle et dans ce cas là, à la fin de chaque réunion on peut mettre en évidence, sur le tableau des décisions, le nom du nouveau facilitateur, pour que les autres puissent faire appel à lui pour une médiation par exemple.

Des réunions plus courtes, davantage d’efficacité opérationnelle, une équipe plus soudée avec des individus entendus et pas seulement écoutés, dites moi où c’est que l’on signe.

MOOCs aren’t stabs

« MOOCs aren’t stab » clearly inspired by « Mocks aren’t stubs » an article of Martin Fowler well known by developers because it lighten a confusion between two approaches of emergent design: classical TDD and mockist TDD.

As a developer autodidact, I can’t pass through the phenomenon of MOOC, and find the parallel with Martin Fowler article funny.

 Let me hope I can lighten you about it.

Some teachers are reluctant against MOOC.

Set apart that in France teachers are just unwilling changes due to successive fails in educational reforms, they have arguments to protest against MOOC.

First, they loose their central role.

That’s not a joke, teaching can be a thankless task and the main reward teachers have, is their responsibility in the achievement of their students. Gratitude is not known as the best quality of students, so imagine if they have the feeling that they build their knowledge themselves.

Teachers are not “people who increase taxes”, neither nannies responsible of the bad education of your children, they are the future, the guarantors of the sane evolution of our societies. They merit gratitude, and they have the right to claim gratitude.

Connectivism, require more involvement for teachers.

As they aren’t the only source of information for their students, they need to verify sources, facilitate communications, manage students skills… with the fact they need to be proficient into technologies this may give them more work to achieve good results.

Business ride the change

Better education is not the reason why MOOC make the buzz.

First theories about constructivism started in the 1920’s (Lev Vygotsky) , moodle development started in the 90’s, Georges Siemens used publicly the term connectivism since the end of 2004 (see: http://www.elearnspace.org/Articles/connectivism.htm ),…

In april 2012 coursera “a for-profit company” (src: wikipedia) announce they have received $16 million from venture capital, in july $6 extras million from funding and during summer 2012 MOOCs made the buzz.

Wait a minute, are we telling teachers: “now, you’ll have to work more, with less gratitude and make business or marketing to be considered.” ? This sounds like stabs, isn’t it ?

Going further…

My truth, is that rules have already changed since a while.

In the 50’s in France a child of 12 was able to recite each department of our country, nowadays, he will find a map of these departments on the web through his mobile.

The debate is not if it is better or not, this will go on whatever we do and the main reason consists in the fact that computers are better than humans to store data.

Knowledge and technologies grow faster than ever giving us more and more power which force us to think more about how we can manage and use this power in a sustainable way, than wasting our time to do what machines already do.

It’s time to explain the title of this article and the parallel with agile methodologies.

I think the main question agile methodologies tend to answer is about how we deliver value. It’s a bit the same question in education: how we make people to deliver their value.

The practice discussed in Martin’s article consists of iterating over:

  • writing a small test which fail

  • implementing the smallest code that makes the test pass

  • refactoring (a.k.a. improving) the code until it’s acceptable

This practice called emergent design, is well known to make developers in confidence with their code, helping them to progress step by step. Classical TDD focuses on testing what are doing each units (pieces) of code, whether the mockist tests the behavior of these units.

Nowadays as we tend to deliver the maximum of value to our users, most of “TDDist” concentrate their effort on the consistency between user expected behavior of an application and the application behavior itself, and so, mocks tend to become the main stream.

The situation is the same in education, what’s matter nowadays is not to stun others with an eidetic memory, but what we are able to accomplish with all resources we can reach.

Testing if a student can restitute “as is” pieces of knowledge we’ve bring to him will not help him to accomplish himself and being a part of society, whereas, testing his “capacity to deliver value”, his behavior inside a group, a project, a network (in the larger sense) will prepare him to find the needed resources to brave walls dressed along his route.

Humans and technologies are part of our life, connectivism is not a choice, is the actual obvious way.

Sure MOOC aren’t connectivism, it’s just a brick, a tool given to the most important piece of the education gear which is “teachers”.

This term certainly need to be refined, but teachers are those who have to inspire our children to become adults, they have to guide them to their accomplishment in the actual society. This is a task clearly more important and difficult than writing and dealing courses. This is also certainly more exciting and fun than being the controller of the right execution of a given plan.

So please, take the opportunity, if you are in the fewest that consider MOOCs are stabs, think about what they will be if you don’t take part of the movement.