Le jeu du prénom en mode multitâche

Le jeu du prénom en mode multitâche1
ou Combien de temps faut-il pour écrire un prénom ?
Henrik Kniberg
Version : 07-12-2011
Traduction : Cédric Chevalérias (17-12-2011)
1
NdT : Nom original : The multitasking Name Game

Le jeu du prénom en mode multitâche
Henrik Kniberg
Traduction : Cédric Chevalérias 2 / 21
Table des matières
A propos de cet article ............................................................................................................................ 4
Attention intrigue dévoilée !.............................................................................................................. 4
But de cet article et de la simulation .................................................................................................. 4
A propos de la simulation........................................................................................................................ 5
Origine du Jeu Du Prénom En Mode Multitâche................................................................................. 5
Nom de la simulation .......................................................................................................................... 5
Licence................................................................................................................................................. 5
Temps et matériel nécessaires............................................................................................................ 6
En résumé................................................................................................................................................ 6
Description détaillée ............................................................................................................................... 6
Etape 1 : Estimer le temps que cela prend d’écrire un prénom ......................................................... 6
Etape 2 : Discuter des facteurs d’influence......................................................................................... 7
Etape 3 : Créer des groupes et décrire le rôle de Client ..................................................................... 8
Etape 4 : Décrire la politique de production du Développeur pour le premier tour .......................... 9
Etape 5 : Lancer le premier tour........................................................................................................ 11
Etape 6 : Relever des mesures sur ce premier tour .......................................................................... 11
Etape 7 : Faire changer les développeurs de table et présenter le second tour .............................. 13
Etape 8 : Lancer le second tour......................................................................................................... 15
Etape 9 : Relever des mesures sur le second tour ............................................................................ 15
Qu’avez-vous ressenti durant ces deux tours en tant que Développeur ou Client ?................... 16
Comment c’était d’être le dernier client lors du second tour, par rapport au premier tour ?..... 16
Que pensez-vous de l’affirmation « Plus tôt on commence, plus tôt on finit » ?......................... 17
Comment cela influence-t-il le planning de livraison ? Par exemple, que sait-on après 10
secondes du premier tour, et après 10 secondes du second tour ?............................................. 17
Que se serait-il passé si le développeur avait été un expert en changement de contexte ?........ 17
Comment cela influence-t-il la qualité du produit ? ..................................................................... 18
Est-ce que ce problème de multitâche vous semble familier ? Qui le rencontre actuellement ?
Qui l’a rencontré par le passé ?..................................................................................................... 18
Qu’est-ce qui nous pousse à faire cela ? Pourquoi ce problème est-il tellement courant ? ........ 18
Quand est-ce que le mode multitâche est une bonne idée ? Qui en bénéficie au premier tour ?
....................................................................................................................................................... 18
Comment pouvez-vous lutter face à ce problème dans votre environnement ?......................... 19
Simulation à grande l’échelle ............................................................................................................ 19
Variantes............................................................................................................................................ 20
FAQ pour le facilitateur ..................................................................................................................... 20
Durant l’estimation initiale, ne vaut-il pas mieux écrire un intervalle (4-6 secondes) plutôt qu’un
seul nombre ?................................................................................................................................ 20

Henrik Kniberg
Lors de la récupération des résultats, pourquoi n’écrire que la médiane ? ................................. 20
Pourquoi des prénoms ? Pourquoi pas des fruits, des couleurs, ou autre chose ? ...................... 21
Est-ce que la simulation a déjà échoué ? ...................................................................................... 21

Henrik Kniberg
A propos de cet article
Attention intrigue dévoilée !
Cet article est destiné aux coaches, formateurs, et à tous ceux qui cherchent un moyen très amusant
d’illustrer la problématique du multitâches.
Si vous pensez être susceptible d’assister à une de mes sessions sur Agile&Lean (ou celle de tout
autre formateur comme Mary Poppendieck), je vous suggère d’arrêter votre lecture tout de suite.
Lire les détails de cette simulation la rendra bien moins amusante que de l’expérimenter par vous-
même.
Oui, vraiment ! Arrêtez de lire immédiatement si vous pensez que vous avez des chances de
participer à ce jeu dans les mois qui viennent.
But de cet article et de la simulation
Le but de cet article est de décrire une mise en situation qui illustre combien le travail en mode
multitâche est mauvais et comme il est facile de s’y laisser entraîner.
L’article est principalement écrit pour les formateurs et les facilitateurs qui veulent savoir comment
cette simulation fonctionne et comment la faciliter avec succès. Cependant, tout ceux qui liront cet
article pourront probablement mieux appréhender la problématique du multitâche et trouveront les
moyens d’exposer le problème et le résoudre dans leur propre environnement professionnel.
PS : si vous ne savez pas ce que signifie « multitâche », ne vous inquiétez pas. Poursuivez votre
lecture. Voyez cet article comme une définition en profondeur de ce mot ;o)

Henrik Kniberg
A propos de la simulation
Origine du Jeu Du Prénom En Mode Multitâche
En tant que coach, je suis constamment étonné par la quantité de travail fait en mode multitâche
dans la plupart des sociétés avec lesquelles j’ai travaillé, et la quantité de gaspillages inutiles que cela
engendre. Encore et toujours, je trouve qu’une des façons les plus simples et les moins couteuses
d’améliorer la productivité d’une équipe ou d’un individu est d’identifier et de réduire toutes les
sources de multitâche.
Durant des années j’ai essayé de trouver une simulation qui illustre le problème. Si une image vaut
mieux qu’un long discours, une simulation vaut mieux qu’une centaine d’images. J’ai trouvé plusieurs
mises en situations, certaines simples, d’autres complexes, mais aucune qui reproduise le problème
clairement et simplement. J’ai donc emprunté les meilleures idées d’autres simulations et créé la
mienne. A ma grande surprise, elle a très bien fonctionné la première fois (i.e. les participants ont été
fortement touchés par l’exercice, plusieurs ont mentionné que c’était le point fort du cours). Les
années passant, je l’ai constamment amélioré, et il fonctionne encore mieux maintenant.
Cette simulation est maintenant devenue très populaire au sein des communautés de formation
Agile&Lean. L’un des formateurs qui ont adopté cet exercice est Mary Poppendieck. Elle est
habituellement très sceptique au sujet des simulations et ne les inclut pas dans notre propre matériel
pédagogique. Mais, en assistant à cette simulation pendant un atelier lean que nous co-animions,
elle a exprimé énergiquement son enthousiasme et l’a immédiatement adoptée pour son propre
corpus pédagogique. Mary et d’autres formateurs me racontent souvent l’impact de cette mise en
situation, particulièrement sur les équipes de management.
Nom de la simulation
Le nom de cette simulation est « Jeu du prénom en mode multitâche », car c’est exactement ce que
c’est. Cependant, en formation, je l’appelle souvent « Combien de temps faut-il pour d’écrire un
prénom ? », pour ne pas gâcher l’effet de surprise. Ce second nom vient aussi du fait que j’introduis
la simulation en posant cette simple question :o)
Licence
Vous pouvez utiliser cette simulation comme vous le voulez, mais j’apprécierais que vous
mentionniez ou écriviez quelque part qu’elle provient de moi.
L’URL officielle est http://www.crisp.se/henrik.kniberg/multitasking-name-game
Techniquement, la simulation est sous licence Creative Commons (Creative Commons Attribution-
ShareAlike 3.0 Unported License).2
2
Adresse : http://creativecommons.org/licenses/by-sa/3.0/

Henrik Kniberg
Temps et matériel nécessaires
Le cœur de la simulation prend environ 20 minutes (quelle que soit la taille des groupes), et entre 10
et 20 minutes pour le débriefing. Les seuls outils nécessaires sont des stylos, du papier et un
chronomètre ; idéalement des feutres épais (marqueurs pour tableaux blancs par exemple), des
fiches cartonnées et un gros chronomètre projeté sur un écran. L’ordinateur et le projecteur sont
totalement optionnels. La simulation peut aussi bien être facilitée juste avec un « paperboard ».
En résumé
1. Ecrire 5 prénoms, tous en même temps. Mesurer combien de temps cela prend par prénom
et au total.
2. Ecrire ensuite 5 prénoms, un seul à la fois. Mesurer à nouveau.
3. Apprécier le coût du multitâche !
Description détaillée
Etape 1 : Estimer le temps que cela prend d’écrire un prénom
Je me passe de toute introduction préalable et commence par poser cette simple question :
« Combien de temps faut-il pour écrire un prénom ? »
Il y a généralement un moment de flottement, les gens se demandant ce que je veux bien dire avec
cette question. Je montre alors une fiche cartonnée :
« Par exemple comme celle-ci »
Les gens sont tout d’abord un peu réticents à jouer aux devinettes et se réfugient derrière des « ben,
ça dépend ». Pour essayer d’obtenir d’une réponse, je les incite en disant : « vous ne pouvez
vraiment pas estimer ? Vous voulez dire que cela pourrait prendre plus d’un an ? Ou moins d’une
seconde ? ».
Finalement, ils commencent à donner des estimations, généralement autour de 4 secondes.
Je leur demande ensuite combien de temps il faut pour écrire 5 prénoms. Ils trouvent habituellement
autour de 20 secondes (le premier nombre x5).

Henrik Kniberg
J’écris ces nombres au tableau :
Combien de temps faut-il pour écrire un prénom ?
Estimation
1 prénom 4sec
5 prénoms 20sec
Etape 2 : Discuter des facteurs d’influence
Je demande ensuite : « Quels sont les facteurs qui influencent ce temps ? Quand vous dites ‘ça
dépend’, cela dépend de quoi ? ». Les participants commencent à donner leurs idées, et je les note
au tableau. Habituellement, ça donne quelque chose comme ça :
C’est un piège…
Dans la très grande majorité des cas, personne ne fera mention du travail en mode « multitâche »
comme un facteur ayant une influence sur le temps. C’est pourquoi je ne mentionne habituellement
pas le nom de la simulation, je veux démontrer qu’on a toujours tendance à oublier l’influence du
mode multitâche.
Je dis ensuite : « OK, tâchons de trouver la vérité ! ».
Quels sont les facteurs influençant ce temps ?
 La longueur du prénom
 La complexité du prénom
 Les outils (stylo, papier, table, etc.)
 La qualité attendue
 L’aptitude à l’écriture
 … etc. …

Henrik Kniberg
Etape 3 : Créer des groupes et décrire le rôle de Client
Je demande à l’assistance de faire des groupes de 5 à 7 personnes, dans lesquels une personne joue
le rôle de Développeur, et les autres sont des Clients.
La seule compétence nécessaire pour être développeur est la capacité à écrire des lettres sur un
morceau de papier. L’outil utilisé pour ce faire est un feutre.
Voici ce que je dis aux Clients :
Chacun de vous a une fiche vierge. Tout ce que vous voulez, c’est votre prénom écrit sur cette fiche.
Le problème, c’est que vous ne savez pas écrire les lettres – c’est pour cela que vous avez besoin du
Développeur !
De plus, ce que vous, Client, voulez, c’est obtenir la fiche avec votre prénom, le plus rapidement
possible. C’est votre boulot de consigner ce temps, donc quand on vous aura fourni la fiche, vous
écrirez le temps que cela a pris (oui, vous savez écrire les chiffres !). Pour vous aider, je (le facilitateur
de l’exercice) projetterai un grand chronomètre à l’écran.

Henrik Kniberg
Le processus se déroule donc dans cet ordre :
1. Envoyez votre fiche au Développeur, donnez-lui votre prénom.
2. Attendez que le Développeur écrive votre prénom et vous rende la fiche.
3. Notez le temps écoulé au retour de votre fiche.
S’il y a un bug (une faute d’orthographe par exemple), ne notez pas le temps, mais renvoyez la fiche
pour correction. La livraison n’est considérée validée que si la fiche est correcte.
Vous pouvez parler avec le Développeur et répondre aux questions. Ce que vous ne pouvez pas
faire, c’est écrire des lettres.
Les badges et autres cartes de visite sont bien sûr à dissimuler pendant toute la durée de l’exercice.3
Etape 4 : Décrire la politique de production du Développeur pour le
premier tour
Voici ce que je dis aux Développeurs :
Votre travail en tant que développeur est simplement d’écrire le prénom des Clients. Cependant il
est indispensable de suivre la politique de l’entreprise !
Notre politique est de Ne jamais faire attendre un client, c’est mauvais pour le business. Si on fait
attendre un client, on pourrait le perdre. Nous sommes de plus persuadés que plus tôt on commence
quelque chose, plus tôt on le finit. N’est-ce pas ?
A ce moment là, je fais une pause et vérifie consciencieusement que personne ne semble
faire d’objection. Habituellement, personne ne me contredit, car cela semble évident. Un des
buts de cette simulation est de montrer à quel point cette affirmation est fausse.
3
NdT : Si vous réalisez cette simulation avec des personnes qui se connaissent déjà, demandez aux clients de
s’inventer un prénom.

Henrik Kniberg
Donc, pour être conforme à cette politique de l’entreprise, vous, en tant que Développeur, devrez
réaliser tous les projets en même temps !
Quand je démarre le chronomètre, tous les Clients vont simultanément tendre leur fiche en donnant
leur prénom. Vous devrez écrire la première lettre du prénom du premier client, puis la première
lettre du prénom du deuxième client, etc.
Quand la première lettre du prénom de chaque client est écrite, il faut recommencer avec la
deuxième lettre de chaque client, etc.
Dès qu’un prénom est écrit en entier, livrer la fiche au Client pour qu’il puisse écrire le temps de
livraison sur la fiche.

Henrik Kniberg
Voilà le premier tour. Je vérifie que tout le monde a bien compris ces instructions, que tout le monde
est équipé d’un crayon/feutre et que tous les Clients ont une fiche vierge.
Je démarre alors le chronomètre.
Etape 5 : Lancer le premier tour
A ce moment, j’observe les développeurs pour m’assurer qu’ils respectent bien la politique de
l’entreprise (normalement pas de problème, si je l’ai bien décrite).
Les gens s’amusent généralement beaucoup en faisant cela, car tout le monde peut voir à quel point
c’est désastreux, et la plupart reconnaissent des situations similaires à ce qu’ils vivent sur leurs
propres projets.
Il y a beaucoup de communication et de confusion, vu que le développeur doit constamment
demander leur prénom aux Clients, voire dans certains cas leur demander d’épeler.
Parfois les Clients font du micro-management avec le Développeur en lui épelant individuellement
chaque lettre de leur prénom. Ça n’est pas grave, je l’autorise, vu que les résultats sont plus ou
moins les mêmes.
Je vérifie et (si besoin) rappelle aux clients qu’ils doivent écrire le temps sur leur fiche dès qu’ils la
reçoivent (sans erreur).
Quand tout le monde a terminé d’écrire, j’arrête le chronomètre.
Etape 6 : Relever des mesures sur ce premier tour
Je demande à chaque table de reporter la médiane des temps de livraison (« si vous triez les fiches
par temps de livraison, quel est le temps écrit sur la fiche du milieu ?»). J’écris la médiane de ces
résultats (i.e. la médiane des médianes…). Typiquement environ 50 secondes.
Je demande aussi à chaque table de donner le temps de livraison total, c’est à dire le temps qu’il a
fallu pour livrer les 5 noms, et j’écris la médiane de ces nombres, typiquement environ 60 secondes.
Estimé Réel
1 prénom 4 sec 50 sec
5 prénoms 20 sec 60 sec

Henrik Kniberg
C’est le moment pour une petite litanie: « Vous avez estimé que chaque prénom prendrait environ 4
secondes à livrer. Mais cela à pris plus de 12 fois plus de temps ! Je sais que certains chefs de projet
multiplient secrètement les estimations par π, mais dans ce cas, même en multipliant deux fois par π,
on serait encore loin de vos temps de livraison réels ! »
Suit donc la question qui tue :
« Donc, s’il vous plait, éclairez moi. Lequel de ces facteurs a causé ces retards incroyables ? » (en
pointant le tableau)
« Aviez-vous des prénoms incroyablement longs ? »
« Aviez-vous des prénoms si complexes que ça ? »
« Vos stylos n’ont-ils pas fonctionné correctement ? »
« Avez-vous fait de la calligraphie artistique, ou gravé les prénoms dans une tablette en pierre ? »
« Ou avez-vous eu des développeurs vraiment très mauvais ? »
Après quelques rires et discussions, l’évidence apparait : le problème n’avait rien à voir avec ces
facteurs d’influence. Il manque dans la liste de ces facteurs le plus important d’entre eux : le
multitâche ! Je l’ajoute donc dans la liste de façon ostentatoire !
Estimé Réel
1 prénom 4 sec 50 sec
5 prénoms 20 sec 60 sec
 … etc. …

Henrik Kniberg
Les autre facteurs d’influence font pâle figure en comparaison.
C’était un projet on ne peut plus simple – juste écrire un prénom sur un morceau de papier ! Non
seulement le mode multitâche nous a fait exploser les temps de livraison de 1250%, mais il a aussi
réduit notre productivité à un tiers de ce qu’on attendait. On a pensé que cela prendrait 20 secondes
pour écrire 5 prénoms, mais cela a pris 60 secondes !
Le temps du second tour est venu.
Etape 7 : Faire changer les développeurs de table4 et présenter le second
tour
Je demande aux développeurs de changer de table afin que chaque table ait un nouveau
développeur tout frais. Je leur dis qu’ils viennent de commencer à travailler dans une nouvelle
société5
dont la politique est totalement différente.
La politique de cette société est de limiter le TAF (Travail A Faire)6
. Et il se trouve que la limite
actuelle est de 1.
4
NdT : Si vous n’avez qu’un groupe, demandez aux clients de s’inventer de nouveaux prénoms
5
Vu leurs résultats catastrophiques, ils ont été licenciés de la société précédente, ou elle a fait faillite, à vous de
voir…
6
En anglais WIP : Work In Progress
 … etc. …
Le MULTITACHE !

Henrik Kniberg
Cela signifie que le Développeur n’est autorisé à travailler qu’avec un seul Client à la fois. Il ne
commencera donc à écrire « Lisa » qu’après avoir terminé « Dave ». Et la pauvre « Maria » devra
attendre le plus longtemps, son projet ne commencera pas avant que tous les autres clients aient
terminé.
Cela a des implications importantes. Le Développeur a maintenant le contrôle sur son flux d’entrée !
Le Développeur décide quand commencer un projet (il « tire » les projets à lui), et non les clients (qui
« poussaient » auparavant les projet vers lui).
Nous avons donc maintenant un système à flux tiré, au lieu d’un système à flux poussé.
Cela ajoute une nouvelle étape au début de notre processus :

Henrik Kniberg
Le Client n’est désormais plus autorisé à pousser sa fiche vers le Développeur. Au contraire, c’est le
Développeur qui décide quand il est prêt pour le projet suivant et qui tend la main vers un Client en
lui demandant sa fiche et son prénom.
Maintenant, vu que tous les projets ne démarrent pas au même moment, le Client doit consigner le
temps au démarrage de son projet, le temps à la fin de son projet, et calculer la durée du projet en
soustrayant ces deux nombres. Il note donc « Quand ai-je eu ma livraison ? » aussi bien que
« Combien de temps cela a-t-il pris du début à la fin ? ».
OK. Prêt. Encore une fois, assurez-vous que tout le monde a bien compris les nouvelles instructions,
et que les Clients ont de nouvelles fiches vierges (et que les précédentes ont été écartées)
Je démarre alors le chronomètre.
Etape 8 : Lancer le second tour
Observez et amusez-vous.
Etape 9 : Relever des mesures sur le second tour
Une fois que tout le monde a terminé d’écrire, j’arrête le chronomètre et rassemble les statistiques
comme je l’avais fait au premier tour. C’est à dire le temps médian pour avoir un projet terminé (du
début à la fin) et le temps médian pour avoir les 5 projets terminés.
La différence est spectaculaire. Typiquement quelque chose comme ça :
Estimé
Tour 1
(multitâche)
Tour 2
(focalisé)
1 prénom 4 sec 50 sec 5 sec
5 prénoms 20 sec 60 sec 30 sec
Je pointe ces nombres et interroge l’assistance sur la différence entre les deux tours.
Pour le second tour, on a réalisé chaque projet 10 fois plus rapidement (de 50 à 5 secondes) et
comme le temps de projet total a été divisé par 2 (de 60 à 30 secondes), on a aussi doublé la
productivité. Avec les 30 secondes disponibles après le second tour, on aurait pu livrer 5 autres
projets – par exemple 5 nouveaux clients, ou une autre itération avec les 5 mêmes clients (en
écrivant leur nom de famille par exemple).
Voila à quel point le mode multitâche est mauvais, même pour un projet aussi simple que d’écrire un
prénom sur une fiche. Maintenant, imaginez faire quelque chose de complexe, comme écrire un
logiciel par exemple, où le changement de contexte est bien plus difficile. Cela entraîne des délais

Henrik Kniberg
supplémentaires, des problèmes de qualité, et du stress. A l’échelle d’un projet réel, cela peut se
chiffrer en semaines plutôt qu’en secondes, mais les proportions sont souvent les mêmes.
En regardant les premières estimations, on peut voir qu’au second tour, les nombres sont assez
proches de ce qu’on avait pensé à l’origine.
Je montre aussi ce graphique, qui présente un résultat très caractéristique. Si le temps le permet, je
laisse chaque table dessiner son propre graphique.
Ce graphique fournit une bonne représentation de ce que coûte le multitâche. Je demande si l’aspect
de ce graphique ressemble à ce qu’ils ont obtenu avec leurs propres chiffres, et c’est généralement le
cas.
A ce moment, je facilite la discussion. Voici quelques exemples de questions que je pose, et les
réponses typiques que j’obtiens (ou que je m’offre) :
Qu’avez-vous ressenti durant ces deux tours en tant que Développeur ou Client ?
 Le premier tour était stressant et déroutant des deux côtés, le second tour était calme et
concentré
 En tant que client dans le second tour, c’était bien d’avoir une discussion bien canalisée avec
le développeur pendant qu’il était en train de travailler, et après avoir réellement terminé.
Pendant le premier tour le développeur n’a pas arrêté d’aller et venir et répéter des
questions comme « quel était votre prénom déjà ? , avec un K ou CK ?»
Comment c’était d’être le dernier client lors du second tour, par rapport au premier tour ?
 Avoir à attendre ne me dérangeait pas, car je pouvais voir les autres projets se dérouler très
rapidement et je pouvais voir mon tour arriver. Au premier tour, mon projet a démarré
rapidement, mais je n’avais pas la moindre idée du moment où il serait terminé.

Henrik Kniberg
Que pensez-vous de l’affirmation « Plus tôt on commence, plus tôt on finit » ?
 Pulvérisée. Cette simulation montre un exemple du contraire. Au second tour chaque projet
(excepté le premier) a démarré plus tard, et chacun des projets a terminé plus tôt. En fait, au
second tour, les projets ont terminé plus tôt parce qu’ils ont commencé plus tard. Bizarre,
mais vrai.
Comment cela influence-t-il le planning de livraison ? Par exemple, que sait-on après 10
secondes du premier tour, et après 10 secondes du second tour ?
 Après 10 secondes du premier tour, on n’avait aucune idée du moment où quoi que ce soit
serait terminé. Après 10 secondes du second tour, on avait déjà deux projets terminés, on
pouvait donc estimer de manière fiable la fin des projets suivants.
 Pour le premier tour, l’estimation ressemble plutôt à un jeu de devinette, même si tous les
facteurs d’influence (longueur du nom, etc.) sont connus à l’avance, car on ne sait jamais si
un autre projet ne sera pas encore ajouté à la mêlée.
 Pour le second tour, on a pu estimer de façon assez sûre (par rapport au premier tour) même
si l’un des prénoms est particulièrement long et complexe.
Que se serait-il passé si le développeur avait été un expert en changement de contexte ?
 Les 30 secondes de perte de productivité ont été causées par le basculement d’une tâche à
l’autre (temps « perdu » à passer d’un projet à un autre). Mais si le changement de contexte
se faisait sans perte, c’est à dire si le développeur pouvait passer d’un contexte projet à un
autre sans perdre de temps ? Dans ce cas, la différence entre les deux tours ressemblerait à
quelque chose comme ça :
Le temps total pour terminer tous les projets est le même – donc pas de perte de productivité dans
ce scénario. Mais chaque projet pris individuellement prend toujours 5 fois plus de temps en mode
multitâche. C’est à cause de la loi de Little, qui dit principalement que si vous faites X choses
simultanément, chaque chose prendra X fois plus de temps.
Donc ne vous tracassez pas à embaucher des pros du multitâche. À la place, embauchez des
personnes qui détestent le multitâche et qui se focaliseront plutôt à créer un environnement qui
minimisera le besoin de multitâche – à travers des politiques de limitation du TAF, etc.

Henrik Kniberg
Comment cela influence-t-il la qualité du produit ?
 Si le Développeur n’a pas bien compris les besoins du Client (par exemple il orthographie mal
son prénom), il faudrait 50 secondes pour s’en rendre compte lors du premier tour, et
seulement 5 secondes lors du second tour.
De plus, la productivité accrue du second tour signifie qu’on a le temps de parfaire le prénom
si nécessaire. La qualité du produit est donc sérieusement affectée par le multitâche.
Est-ce que ce problème de multitâche vous semble familier ? Qui le rencontre
actuellement ? Qui l’a rencontré par le passé ?
Et là tout le monde ou presque lève la main…
Qu’est-ce qui nous pousse à faire cela ? Pourquoi ce problème est-il tellement courant ?
 On a tendance à vouloir faire plaisir, et il est plus facile de dire « oui » à un nouveau client
que de lui demander d’attendre.
 Au second tour, alors que l’on travaille avec le client n°1, quand le client n°3 arrive à notre
porte et nous demande si nous pouvons démarrer son projet, cela semble bizarre de lui dire
« On commencera votre projet plus tard, comme ça, on pourra le terminer plus tôt »… même
si c’est vrai.
 On se focalise beaucoup trop sur commencer les choses plutôt que sur terminer les choses.
Par exemple en donnant des bonus quand on signe avec un nouveau client, au lieu de donner
un bonus quand on livre effectivement le client.
 On essaie parfois de « capturer » les clients en commençant leurs projets au plus tôt, pour
réduire le risque de les perdre. Mais c’est une proposition perdant/perdant. Cela peut
éventuellement fonctionner sur le court terme, mais s’il y a une compétition intelligente sur
le marché, cette stratégie peut se retourner contre vous sur le long terme. Le marché va finir
par se rendre compte tôt ou tard que la société A réalise ses projets 10 fois plus lentement et
pour 2 fois plus cher que la société B.
Quand est-ce que le mode multitâche est une bonne idée ? Qui en bénéficie au premier
tour ?
 Le multitâche est presque toujours une mauvaise idée. Personne n’en bénéficie au premier
tour.
 Un multitâche limité peut être utile dans les situations où un projet A est bloqué car en
attente de quelque chose, et on peut donc avancer sur le projet B entretemps. On doit
cependant limiter cela, par exemple à deux projets simultanément. En faisant cela, on crée
une pression pour traiter les obstacles plutôt que persister à démarrer de nouveaux projets.
 Un point important à retenir est si la limitation du TAF est importante, cette limite ne doit
pas nécessairement être fixée à 1. N’importe quelle limite vaut mieux que pas de limite du
tout.
Voici l’exemple d’une équipe travaillant sur 4 projets en parallèle. Les zones épaisses montrent
quand l’équipe travaille réellement sur chaque projet.

Henrik Kniberg
Voila ce qui se passe si on limite le TAF à 2 projets – un « projet principal » sur lequel on se focalise,
et un « projet de fond » sur lequel on ne travaille que lorsque le projet principal est bloqué. Pour le
projet principal, on a un plan de livraison et des engagements, sur le projet de fond, on n’en a pas.
Comment pouvez-vous lutter face à ce problème dans votre environnement ?
Vous pouvez faire une quantité de choses, quel que soit votre rôle dans votre organisation.
 Visualisez le problème. Rassemblez des mesures sur les projets existants, dessinez le
graphique ci-dessus.
 Mesurez le niveau de multitâche. Demandez aux gens de faire la liste des projets sur lesquels
ils sont impliqués. Ou gardez à portée de main une feuille sur laquelle vous notez
systématiquement chaque fois que vous êtes contraints à changer de contexte. Consolidez
ces données avec l’équipe entière et discutez des moyens à mettre en œuvre pour réduire le
multitâche.
 Jouez au « jeu du prénom en mode multitâche » avec vos collègues, managers, clients, etc.
Cependant, gardez bien à l’esprit que le premier pas, et le plus important, est de faire prendre
conscience aux gens qu’il y a un problème. Là seulement vous pouvez effectivement le résoudre.
J’espère que cet article aidera !
Simulation à grande l’échelle
Cette simulation fonctionne le mieux en petits ateliers (entre 10 et 20 personnes) groupés autour de
petites tables, propices aux discussions et débriefings. Cependant elle marche aussi pour des groupes

Henrik Kniberg
de centaines de personnes. S’il est impossible de faire des petits groupes autour de tables
(auditoriums sans tables, ou assistance trop nombreuse), vous pouvez la jouer sur scène.
Par exemple, invitez sur scène deux groupes de 6 personnes. Placez chaque groupe devant un
tableau. Au lieu d’utiliser des fiches cartonnées pour écrire des prénoms, les développeurs écrivent
au tableau, et les clients écrivent le temps de livraison à côté de leur prénom une fois qu’il est
terminé. A part cela, la simulation se joue de la même façon.
Cela marche aussi en invitant un seul groupe si vous ne disposez que d’un tableau. Le seul
inconvénient, c’est que vous ne pourrez pas permuter le développeur aussi facilement.7
Variantes
Cette simulation peut bien sur être étendue ou ajustée pour illustrer d’autres choses. Par exemple :
que se passe-t-il si le client change d’avis au milieu du projet, ou décide (après la livraison) qu’il veut
en fait tout en lettres majuscules, ou écrites en vert ? Et si on ajoute des aspects financiers, comme le
paiement au moment de la livraison, ou de retour sur investissement ?
Je n’ai cependant pas trop expérimenté ces variantes, jusqu’à maintenant, je me suis attaché
fortement à l’aspect multitâche de cette simulation.
FAQ pour le facilitateur
Durant l’estimation initiale, ne vaut-il pas mieux écrire un intervalle (4-6 secondes)
plutôt qu’un seul nombre ?
Techniquement, oui. Donner un intervalle montre que l’estimation est donnée avec un niveau
d’incertitude. Mais tous ces chiffres supplémentaires compliquent la simulation en rendant le
tableau moins lisible. Cette simplification est donc bien intentionnelle.
Lors de la récupération des résultats, pourquoi n’écrire que la médiane ?
J’écrivais auparavant la totalité des résultats au tableau, mais cela devenait déroutant. Souvent 10%
des participants trouvent des résultats vraiment bizarres, par exemple parce qu’ils ont un prénom
incroyablement court, ou parce que quelqu’un a laissé tomber son stylo, ou parce que le
développeur a fait une faute d’orthographe dans le prénom et a dû le réécrire, ou parce que le client
s’est trompé dans le temps de livraison qu’il a noté. La médiane est le nombre le plus pertinent.
Je trouve aussi que tous les détails additionnels notés sur le tableau diluent le message, vu qu’on
s’attache souvent plus à comprendre la signification de tous ces chiffres au lieu de se concentrer sur
l’objet de l’exercice. Je le garde donc simple.
J’utilise la médiane plutôt que la moyenne car elle est plus facile à trouver, et ne nécessite pas de
calculatrice. La médiane de *12, 20, 24, 25, 50+ est 24. La moyenne est … euh… on s’en fiche.
7
NdT : ou dites aux clients de s’inventer un prénom ! ;-)

Henrik Kniberg
Pourquoi des prénoms ? Pourquoi pas des fruits, des couleurs, ou autre chose ?
Les prénoms sont utiles car chaque Client en a déjà un (je n’ai pas besoin de lui en assigner un), et il
peut y avoir quelquefois des spécificités non triviales (orthographe spéciale, etc.), qui sont une bonne
source de conversation entre le Client et le Développeur, et éventuellement de bug ! Cela semble
aussi plus « réel » avec des prénoms ; les gens se voient plus dire « j’ai besoin de quelqu’un pour
écrire mon prénom » plutôt que « j’ai besoin de quelqu’un pour écrire le nom de ce fruit »
Et, comme effet de bord positif, chacun apprend le prénom des autres :o)
Est-ce que la simulation a déjà échoué ?
Pas que je me souvienne. De temps en temps, j’ai un participant qui soutient que le premier tour
représente une meilleure stratégie de vente, et que « capturer » les clients est une bonne idée. Mais
cela soulève généralement des protestations des autres participants, et des discussions très
intéressantes sur les vues à long terme plutôt qu’à court terme. Je n’appellerais donc pas ça un échec
de la simulation.
Parfois un des groupes n’assimilera pas correctement les instructions et ne suivra pas la Politique de
la Société au premier tour, ce qui faussera leurs statistiques. Mais je ne m’intéresse alors qu’aux
chiffres des autres groupes, ou je rejoue le tour.
Parfois il y aura un développeur exceptionnellement bon au basculement de contexte, ce qui peut
diluer un peu les résultats. Mais ça n’a pas posé de problème majeur jusqu’à maintenant.
Parfois un client sera exagérément enthousiaste et commencera à jouer un rôle de « client difficile »,
en changeant ses demandes et en étant particulièrement pointilleux sur la qualité. Dans ce cas, je lui
demande poliment de la jouer « cool ».
Parfois quelqu’un se plaindra que la simulation est trop simpliste, et que cet effet « multitâche » ne
s’applique pas aux projets « réels ». Le reste de l’assemblée fournira généralement de solides contre-
arguments, donnant des exemples tirés de leur propre expérience. Assez intéressant à voir.
Comme conclusion, je rappelle aux participants que ce n’est qu’une simulation, par définition
artificielle. C’est à chacun de décider ce qu’il y a à en apprendre, et comment l’appliquer dans son
propre contexte.

Le jeu du prénom en mode multitâche

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Le jeu du prénom en mode multitâche

Similar a Le jeu du prénom en mode multitâche (20)

Más de Fabrice Aimetti

Más de Fabrice Aimetti (20)

Último

Último (20)

Le jeu du prénom en mode multitâche