Article InfoQ sur “Jeu de rôle et Management”
Un journaliste d’InfoQ m’a interviewé suite à ma session “Leçons de management d’un maître de donjons” à AT Bruxelles. L’article aborde le lien avec l’ agile et la facilitation, tandis que ma session évolue surtout autour de mon vécu de maitre de jeu, sans forcer le parallèle avec les aspects professionnels. Bref, c’est là :
http://www.infoq.com/news/2013/10/roleplaying-games-agile-coaching
Session parlant de jeux de rôle et de management ? Challenge accepted !
Ca devait arriver : une relation professionnelle s’est égarée sur ce blog et m’a pris au mot. Bruno Sbille, organisateur de la conférence Agile Tour Brussels, m’a proposé un défi : faire une session sur les leçons tirées de la pratique du jeu de rôle -en anglais.
Depuis quelques temps je voulais revenir à des sujets décalés, forcément ça m’a piqué au vif. Après une petite fouille intellectuelle, je lui ai proposé ça (version traduite)(*) :
Titre : Manager sans autorité : leçons apprises en tant que maître de donjon
Je joue à Donjons et Dragons avec des potes tous les un à deux mois. Mon expérience en jeux de rôles approche des 20 ans, bien plus longue que mes 10+ années d’expérience professionnelle.
Au bout du compte, il se pourrait que mes meilleurs leçons de management, de facilitation et de leadership soient plus issues de ma maîtrise des parties que du boulot.
Au départ, vous essayez simplement de faire jouer à vos amis une belle aventure. Pas de patron, pas d’argent en jeu, juste un but commun : se faire plaisir tout du long.
Quel est le problème ?
Comment dire… donnez-leur des épées, quelques sorts, et des trésors, et vous vous retrouverez avec des joueurs retors, des tricheurs, des comportements impulsifs, égoïstes, et des casse-couilles. Le défi : ramener autour de la table les potes intelligents et cools du départ, afin de leur faire jouer la plus belle partie de leur vie.
Je vais partager ce que j’ai appris sur – en vrac – la facilitation, se comporter en meneur / suiveur, le management en binôme, l’improvisation.
Retours et points d’amélioration
AT Brussels s’est déroulée le 27 Septembre. J’ai reçu de bons retours, et quelques points d’amélioration :
- Pour les participants, l’histoire de mon évolution en tant que maître de jeu résonne bien avec des situations professionnelles, elle est inspirante.
- Je n’analyse pas en détail le parallèle avec le management, mais ce n’est pas annoncé clairement au début ; à clarifier, donc, pour éviter de laisser les participants dans l’attente.
- Si j’arrive à remanier le plan, des échanges pourraient être ajoutés en cours de route pour approfondir ensemble sur les situations de management.
- Mystère : mon chrono s’est coincé à “il vous reste 25 minutes” et j’ai dépassé le temps, convaincu d’être dans les clous. Je ne supporte pas les speakers qui ne respectent pas le temps, ben voilà je l’ai fait. Je change de chrono.
- J’ai kiffé faire cette session. Je voulais du sujet qui m’amuse, objectif atteint.
Cerise sur le gateau, construire le sujet m’a apporté beaucoup de recul, j’ai compris plein de choses, découvert que mon évolution en tant que maître de jeu avait suivi une progression par paliers très marquée. (un prochain article ?).
La suite
J’ai proposé cette session à A.T. Paris (5 décembre) et A.T. Lille, on verra si elle est sélectionnée.
(*) Version anglaise / originale :
MANAGING WITHOUT AUTHORITY : LESSONS LEARNT AS A DUNGEON MASTER
I’m playing Dungeons and Dragons with a pack of friends every one or two month. My role-play experience is nearly 20 years long, much longer than my 10+ years of professional experience. I think some of my best management, facilitation and leadership lessons come from game mastery more than from work.
As a dungeon master, you simply try to have your friends playing an inspiring adventure. No boss, no money involved, just a common goal : enjoy every bit of it.
So where’s the deal ?
Well, give your players swords, spells, and treasures, and you’ll have to deal with nasty behaviors, cheaters, impulsiveness, selfishness, and even bullies. Your challenge : have your smart, fun, educated friends back on the table, as to play together the best adventure they never played.
My purpose is to share what I learned regarding leadership, facilitation and management while no authority was involved. As a quick pick, you’ll hear about leadership/ followership, pair management, delegation, facilitation, loosing control, improvising, involving and enrolling (and even a bit of lean !).
Rétroaction et systémique : la cafetière perverse
Puisqu’on est dans les histoires de café (j’en ai pas mal) et de rétroaction systémique, laissez-moi vous en conter une autre, qui se termine bien cette fois-ci : l’histoire de la cafetière perverse.
RIP madame Dosette
Chez Octo, mon précédent employeur, nous avions comme tout le monde une cafetière Nespresso professionnelle (la version avec les capsules plates). Bonne
présentation, grand choix de capsules, détection des pannes. Un genre de majordome du café, éduquée et classe.
Pourtant, soumise à une utilisation intensive par des dizaines de consultants, la belle se mettait parfois en arrêt maladie. Elle restait digne, ne faisait pas de cirque.
en panne, contacter un réparateur, merci de votre compréhension, bisous
Et ce, de plus en plus souvent.
Si régulièrement qu’on appelait le réparateur par son prénom. Certains buveurs de café devenaient eux-même dépanneur pour les pannes les plus simples (votre serviteur s’enorgueillit de savoir détordre et retirer une capsule coincée avec seulement 2 touillettes plastique et du doigté).
Finalement, la machine rendit l’âme.
Retour au naturel 
Un peu échaudés par l’expérience précédente, la communauté des buveurs de cafés tint palabre afin d’investir dans un modèle adapté à ses besoins. Fini le moderne qui se coince, nous nous tournerions vers un modèle plus traditionnel. Un qui moud le café, ce qui est écologiquement plus responsable que les dosettes. Qui fournit de l’eau bouillante pour les buveurs de thés. Choisir nous-même les grains de cafés, sentir leur odeur brute quand on les verse, presque un retour à la terre.
Emplis de cette promesse de jours meilleurs, nous avons commandé la nouvelle machine. Elle est bien arrivée, mais dès les premières salutations, elle nous a mal parlé.
Même sans électronique, un moulin à café, ça reste de la mécanique, qui demande un peu de maintenance. Sur ce point, le modèle était intransigeant.
Lorsque son bac de récupération était plein
vider le marc
Ni merci, ni bonjour. Si vous ignoriez le message pendant 2 ou 3 cafés, non seulement la machine se bloquait, mais punition supplémentaire : le bac déborderait au prochain vidage.
Anecdote classique :
9h30 – Frédéric se fait un petit noir. Juste après, la machine affiche “vider le marc”
9h32 – Gérard passe outre (en faisant une blague, “Marc est pas là”, rigolez pas on l’a tous fait), se fait un café. Rien à signaler.
9h33 – Laurent fait pareil, pas de problème non plus
…
9h38 – Louis veut un café, il voit le message. Discipliné, il ouvre le bac pour le vider, et paf ! Du marc partout, sur ses chaussures, le sol, la table.
Depuis leur bureaux, Gérard et Laurent entendent Louis gueuler dans la cafèt. “Quelle poisse, ce Louis, il a encore des problèmes avec la cafetière”.
Je précise que du marc de café, c’est marron, humide et fumant, c’est dégueu. On voulait du naturel, on en a eu.
Dehors le tyran !
En somme, cette machine était non seulement tyrannique mais perverse : ses instructions valaient exécution immédiate, mais en cas de négligence, elle punissait n’importe qui, se foutait de savoir si c’était le responsable, ni même s’il comprenait pourquoi.
Avec les premiers marcs de cafés par terre vinrent les engueulades (“qui n’a pas vidé le café à temps ?”), les tensions dans la communauté (“c’est encore les jeunes de la mobilité”), les débats sur la meilleure manière de gérer le problème (“comment initier tout le monde aux subtilités d’une cafetière ? qu’en dit le Lean management ?”), et autres envolées sur la tragédie du bien commun.
Autant dire qu’elle s’est rapidement mis des gens à dos. Sous couvert d’analyse systémique, de réflexion lean et d’une bonne dose de mauvaise foi, nous passions d’une recherche de solution à celle d’une rupture de période d’essai. On montait point par point son dossier.
- «c’est une source de tensions»
- «on peut difficilement faire adhérer à un processus des consultants dont la présence est volatile»
- «si nous tolérons cette mauvaise ergonomie, quelle image ça donne aux client ?»
- «elle punit injustement, ce n’est pas conforme aux valeurs de notre entreprise»
A ce stade, quizz : saurez-vous deviner ce qui s’est passé ?
[poll id=”2″]
Réponse plus bas :
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
Rien.
On a tergiversé, mais on a rien fait. Car après quelques temps, on en a plus entendu parler.
Les incidents de marc de café sont devenus rares, on a perdu de vue notre ami le dépanneur, et les philosophes du bureau sont passés à un autre sujet.
A la dure, la communauté avait finit par apprendre le processus, s’était auto-disciplinée : quand la machine parle, on obéit, on a du café, et le marc ne se renverse pas. Si l’un d’entre nous est puni c’est que l’un d’entre nous a fauté, on règlera ça entre nous.
La cafetière nous a mis au pas.
Pour moi dont le métier est de provoquer le changement, cet événement fut un message d’espoir : une boucle de rétroaction aussi injuste et mal foutue peut fonctionner ! Sa seule qualité notable était de se répercuter dans un temps court, généralement moins de 10 minutes. Pour le reste, elle était pourrie. Je n’hésite pas à le dire : peu de personnes ont réussi à discipliner la communauté de mes anciens collègues avec autant de simplicité que cette fruste machine.
Le message de cette anecdote : si vous êtes un acteur de changement, que vous vous demandez comment réguler un système défaillant, ne cherchez pas la rétroaction parfaite, installez la première rétroaction que vous arrivez à faire, et vous l’affinerez plus tard si elle marche.
La cafétéria qui résistait au ménage, un échec systémique
Lorsque je bossais à Octo en 2005, la boîte comptait moins de 70 personnes. Les consultants allaient chercher à manger dans les bouibouis environnants, on mangeait sur la terrasse, et chacun jetait à la poubelle ses restes, sacs et emballages de nourritures.
Avec le développement de la société les années suivantes, certains ont commencé à s’inquiéter : de plus en plus de sacs en papiers oubliés, des tables pas toujours nettoyées (miettes et compagnies). On était pas encore au niveau d’un squat d’étudiants, mais tout de même, emmener des clients dans notre pièce à vivre devenait gênant.
Quick fix
Une solution fut mise en place discrètement : à 14H, une assistante balançait ce qui traînait et passait un coup sur les tables. Personnellement, je ne m’en suis pas rendu compte. A la réflexion, la cafét’ paraissait même plus en foutoir qu’auparavant.
Avant le coup de torchon de 14H, c’était pas plus classe, et après, le foutoir semblait se réinstaller plus vite. Des cocas de l’après-midi commençaient à traîner, des gobelets de cafés à être abandonnés sur les tables, au milieu des miettes du quatre heure.
Expliquer ce phénomène n’est pas le point central de ce billet, mais j’aimerai quand même m’y essayer. On tend spontanément à incriminer, au choix, les nouveaux / les anciens / les crados, bref toute une catégorie d'”autres” qui seraient des méchants pas polis. Personnellement, j’assure que mes collègues étaient des gens très biens et respectueux des autres, peut-être étourdis, mais pas à ce point là. Avec du recul, je pense que ces comportements étaient induits par le contexte.
Croyance en un environnement autonome
Aucun employé de bureau ne vide ses poubelles le soir, ou ne commande de feuilles pour la photocopieuse de l’étage. On perçoit les bureaux comme des systèmes autonomes, on suppose que de mystérieux services généraux se chargent de tout ça.
La cafétéria était devenue autonome : lorsqu’on oubliait de ranger son sac de sandwich, le sac avait généralement disparu avant la pause café de 16H. Pas besoin d’une réflexion consciente pour que la complaisance s’installe. Pour les nouveaux, la cafétéria n’avait jamais fonctionné autrement, donc il ne voyait pas le problème. Quant aux anciens, sachant que l’assistante passait, nous ne poussions plus de gueulante après les collègues indélicats, nous préférions le consensus.
Traiter le symptôme
Sans approfondir sur les détails du comment et du pourquoi, le constat est là : la solution “assistante” n’était pas seulement inefficace, elle avait fait empirer la situation. Cette anecdote, dont je n’ai toujours pas trouvé la solution, me fait encore réfléchir et m’invite à l’humilité.
Scrum Master, manager, facilitateur, on ressent souvent le besoin d’agir, de se rendre utile face à un obstacle de l’équipe. On est tenté de prendre la solution en main, de “passer un bon coup de chiffon”. Mais face à un phénomène complexe, on prend le risque de soigner un symptôme, ce qui incite le système dans ses travers. Je ne dis pas qu’il ne faut pas essayer, mais toujours garder du recul sur l’évolution de la situation globale.
Exemples concrets que j’ai régulièrement croisés :
- un développeur senior qui repasse derrière ses collègues pour nettoyer le code
- un scrum master qui met en oeuvre les actions d’amélioration décidées par l’équipe
- un chef de projet chez un prestataire qui fait l’interface avec le client car ses développeurs ne sont pas très diplomates
Si c’est votre cas, vous pouvez évaluer votre effet réel en posant la question à un observateur extérieur : “objectivement, la pièce parait-elle plus propre depuis que je fais le ménage ?”
(EDIT : article remanié et renommé suite à quelques feedbacks)
De développeur à Scrum Master : 5 clés pour bien démarrer
Avec la propagation des méthodes agiles, il est fréquent que des développeurs soient désignés Scrum Master. Code, architecture, configuration : on apprend en permanence, pas de problème. Mais pour un rôle dont l’essence n’est absolument pas technique, l’apprentissage est plus difficile.
Après un ou deux projets agiles, on pense connaître la méthode, on va simplement reproduire ce qu’on a vu faire. Et puis arrivé de l’autre côté du miroir, on s’aperçoit qu’on en maîtrise pas tant que ça les ressorts, qu’il nous manque des détails, que face à des aspects spécifiques du projet on ne sait pas quelle réponse donner. Et bien sûr, vos coéquipiers, voir vos supérieurs, comptent sur vous. La pression.
Développeur devenant Scrum Master pour la première fois, cet article est pour toi : quelques recommandations pour acquérir un maximum de confiance au démarrage. Je me focalise sur l’animation des réunions et de la rétrospective, mais les principes de fond s’appliquent à l’ensemble de ton action dans le projet.
Tout d’abord, on se rassure. Des personnes avec des profils et des personnalités différentes sont devenues d’excellents Scrum Master. C’est facile, ça s’apprend, c’est juste un peu déroutant au début.
1) Préparer et dé-préparer les rituels
Les rituels sont déjà posés dans le calendrier de l’équipe : planning d’itération ; démonstration + rétrospective ; stand-up meeting. Mais pour le Scrum Master, un temps de préparation est nécessaire afin de ne pas arriver à la course :
- préparation mentale : 10 minutes.
Réviser le déroulement de la réunion, récapitule les ateliers, répète les introductions que tu feras. Réfléchit aux problèmes délicats qui pourraient être abordés : tu devras garder de l’énergie pour rester au dessus de la mêlée dans ces moments là. - logistique : 15 minutes.
Vérifie et règle les points techniques (salle, projecteur, réseau, post-its, marqueurs, etc)
Le meilleur moyen de toujours se préparer, c’est d’inscrire cette préparation dans son calendrier plutôt que dans sa tête : un rendez-vous de 25 minutes avant les rituels, avec répétition automatique à chaque itération.
À présent, quand les participants arriveront en réunion, ils te trouverons déjà là, bien en confiance. Et si tu te fais confiance, ils te feront confiance.
Puisqu’on parle de calendrier, du temps en sortie de réunion doit être réservé :
- mise en oeuvre des décisions : 1H, dans la demi-journée suivant la réunion.
Si des décisions concernant le backlog ou le tableau de bord de l’équipe ont été prises, le plus simple sera de les mettre en oeuvre dans la foulée. Donc idem : calendrier, rendez-vous de 1H, répétition à chaque itération. - décompression : 1H à 2H après la rétrospective.
Le rôle de facilitateur est hors de ta zone de confort, tu fatigueras vite. Rester au dessus de la mêlée, ne pas se laisser entraîner dans les émotions du groupe, ça prend de l’énergie. Beaucoup d’énergie. Donc évite les tâches compliquées dans la foulée, tu n’auras peut-être pas l’énergie pour les réaliser. Préserve-toi, l’équipe a besoin de toi.
Au bout du compte, le rôle de Scrum Master devrait prendre environ 20% de ton temps. Lors des 80% restants, tu seras un développeur comme les autres. C’est un rôle, pas un poste à plein temps.
2) Se focaliser sur le cadre des rétrospectives
L’animation des rétrospectives est la partie qui m’impressionnais le plus quand j’ai débuté comme SM. Plus que l’animation elle même, c’est de veiller au bon déroulement qui était stressant : que les participants restent dans les temps, évitent les digressions, s’assurer qu’ils ne se coupent pas la parole, etc.
En introduction de réunion, il est essentiel de poser Le Cadre : un accord passé entre les participants pour tirer le meilleur parti du temps passé ensemble.
Introduis la séance en rappelant ce cadre :
- le but de la réunion (vérifie s’il y a d’autres attentes si tu as un doute)
- le temps prévu (demande si certains ont des contraintes de temps)
- les participants et leurs rôles, si c’est la première fois ou que des nouveaux participent
- le déroulement prévu, et le découpage du temps que tu proposes (vérifie que tout le monde acquiesse)
- les règles éventuelles
A présent, comme chacun connait le cadre, il comprendra tes interventions, et tu pourras t’y référer pour recadrer la réunion. Sans cadre, pas de recadrage possible. Si tu t’aperçois que tes interventions ne sont pas comprises, c’est le plus souvent parce que les participants ne comprennent pas leur justification : fais dans la pédagogie, repars du cadre. Exemples :
- “je vais te demander de conclure rapidement, sinon le tour de table va durer trop longtemps et nous n’aurons pas le temps de discuter les points ensuite”
- “je vous propose d’en parler plus tard, car là c’est la démo, on a dit qu’on vérifiait juste les user stories et qu’on ne ferait pas d’exploration”
- “est-ce que vous êtes toujours dans le sujet de la réunion ?”
Si les participants grognent, renvois la décision sur eux : «souhaitez-vous prendre plus de temps ?», «est-ce que vous voulez qu’on change l’agenda de la réunion ?», «est-ce que vous souhaitez interrompre le tour de table pour parler de XXX ?». Le facilitateur doit veiller au respect du cadre, mais ça n’empêche pas de le changer si tout le monde est d’accord.
N’aies pas peur si tes réunions ont l’air protocolaires les premières fois : tu feras le mariole quand tu seras à l’aise.
3) Ne pas entrer dans les discussions lors des rétrospectives
Pour réussir ses premières facilitations, le secret est de rester en dehors des débats. N’aies qu’un seul objectif : le déroulement de la réunion, pas son contenu. Si ça t’es difficile au départ, un exercice extrême : n’écoute pas les discussions.
Rentrer dans les débats, c’est THE erreur de facilitateur, celle qu’on voit le plus, qu’on a tous fait, que personnellement je refais régulièrement. Il est très difficile et fatiguant de passer d’une position à l’autre, de s’engager dans les discussions puis d’en sortir. Pris dans les échanges, on oublie de gérer la réunion et elle dérape : les autres s’appuyaient sur toi pour veiller au cadre, mais tu étais occupé à participer…
Je sais, parfois ça va être très dur : par exemple, quand tu auras une solution à proposer au problème dont parlent tes coéquipiers. J’insiste : ne propose pas
ton idée, ne t’en mêle pas. Laisse leur le contenu, reste sur le cadre. Être facilitateur, c’est comme faire une fête chez soi : on en profite peu, mais ça fait plaisir que les invités s’amusent.
Avantage : en renonçant à participer, ton sens de l’écoute et de l’observation vont se développer instantanément. Tu comprendras des choses sur les rapports dans ton équipe, tu verras beaucoup plus de détails sur les comportements des uns et des autres, et sur la dynamique de la réunion. On pourrait dire que tu verras les discussions en mode DEBUG et plus seulement en mode INFO ou WARN.
4) Assumer sa légitimité
Souvent lorsqu’on débute on hésite sur la position à adopter : faut-il être strict sur les règles, peut-on se montrer directif, etc. On doute d’avoir le pouvoir
d’agir, et de la manière de l’utiliser. Le secret : ce pouvoir, ce sont tes coéquipiers qui te l’ont donné. Ils sont d’accord pour que tu agisses. Ils t’ont désigné Scrum Master.
Une fois que tu as saisi cette dynamique, tu peux leur demander de l’aide sans remettre en cause ta légitimité :
- demander ce qu’ils attendent de toi, en réunion ou à l’occasion d’un café avec un collègue. Exemples :
«Je vois qu’on a débordé de 20 minutes ; la prochaine fois vous voulez que je sois plus strict sur la montre ?»
«quand vous avez dérapé sur le sujet du bug, vous auriez voulu que je vous coupe ?» - déléguer certaines tâches ou responsabilités :
“quelqu’un veut bien noter les décisions ?”,
“Mathieu, tu fais les rappels de temps ?”,
“Philippe, tu voudrais maintenir à jour le tableau de bord ?”
Tes coéquipiers t’ont attribué un rôle et des responsabilités mais ils ne t’ont pas laissé seul : n’aies pas peur de leur demander leur aide.
Effet kiss cool : quand on est un peu expérimenté, on peut contredire le conseil 3) “Rester en dehors des discussions” en délégant toute la facilitation à un collègue le temps de la discussion, puis reprendre le lead de la réunion. … Mais pour tes débuts, disons les 3 premières rétrospectives, n’y pense même pas, ne joue pas avec le feu (j’aurais même pas dû en parler…)
5) Echanger avec ses pairs
Un dernier point trop souvent oublié : on comprend souvent mieux la situation et ce qu’on doit faire quand on en parle avec quelqu’un. Echanger avec des
personnes hors de ton projet te feras prendre du recul et progresser (d’autres Scrum Master, des coachs agiles, un mentor, etc). D’autres pratiquants n’attendent que toi pour échanger dans une des nombreuses rencontres agile (les franchises ne manquent pas : Agile Tour, Agile France, Scrum Days, FSUG, Agile .Net, etc).
Voilà, ça devrait t’aider à éviter les principaux écueils.
Chaque Scrum Master apporte un peu de son caractère à son équipe. Certains apportent une forte cohésion par leur empathie, d’autres amènent leur passion pour les métriques, certains documentent beaucoup : chacun son style. Tu veux être un bon Scrum Master ? Sois toi-même, fais les choses à ta manière, et développe ton style. Que le post-it soit avec toi.
La malheureuse histoire du second Scrum Master
Je voudrais éclaircir un point concernant le rôle du Scrum Master. Parfois on m’a demandé mon avis sur des SM qualifiés de “mauvais”, d’autres de “bons”, et j’ai découvert un effet récurrent qui nous pousse à mettre trop d’exigence derrière ce rôle.
La malheureuse histoire du second Scrum Master
Dans les équipes qui démarrent en agile, le choix du Scrum Master se porte souvent vers la personne qui a le plus d’influence sociale. Ses coéquipiers sont habitués à le voir dépanner des problèmes, les gens l’appellent souvent à l’aide ; son nom vient comme un choix naturel lorsqu’il s’agit de trouver un M. Résoud-les-problèmes. Dans notre cas, appelons-le Jean.
L’équipe se repose sur lui pour la plupart des interactions avec le reste de l’entreprise (les autres équipes de dev, l’exploitation, voire le reporting aux instances supérieures). Jean serait le “bon Scrum Master”.
Puis vient un nouveau projet, une nouvelle équipe, un nouveau Scrum Master, appelons-le Kevin. A son tour, on le charge d’assurer les interactions externes, avec pour instructions : “le Scrum Master assure la communication de l’équipe“, voire même “il protège l’équipe des interactions extérieures“. Seulement le jeune homme est moins influent que son prédécesseur, il n’a pas les réseaux, moins de légitimité, et moins de talent relationnel. Au départ il est un peu dérouté. Puis débordé. Tout passe par lui mais Kevin n’a pas le temps ; parfois, il se montre maladroit. Il devient un frein à la communication extérieure. On le compare. On commence à le désigner comme un “mauvais Scrum Master”.
Le talent ne peut être une règle
Polariser les relations entre l’équipe et son environnement sur une seule personne en fait presque toujours un goulet d’étranglement… Sauf pour quelqu’un de très talentueux sur le relationnel, comme Jean.
Ce talent, c’est un coup de chance. On ne peut construire une pratique standard dessus, applicable par toute équipe. La définition en agile du rôle de Scrum Master est plus simple : c’est un facilitateur, il est responsable de l’amélioration continue de l’équipe. Chacun le décline à sa manière, apporte sa touche personnelle, et compose avec ses autres rôles (développeur, chef de projet, business analyst, etc.). Jean utilisait beaucoup la communication, Kevin fera autre chose.
Je ne sais pas si Kevin est bon ou mauvais, mais je pense que si on lui lâche un peu la grappe avec son prédécesseur, il pourra sûrement exprimer ses propres talents.