Les simulations comme outil de perfectionnement du coach

Depuis environ trois mois, nous réalisons des simulations dans le but d’améliorer nos compétences en tant que coach, lors de nos rencontres caddy¹ bimensuelles.

Ces rencontres, dans ce nouveau format, sont maintenant pour moi d’une richesse incroyable. Il y a environ deux mois, j’étais acteur de l’une de ces simulations avec Dominic qui jouait le rôle de golfeur, jouant pour ma part le rôle de caddy.

Cette expérience a été difficile pour moi, mais elle a aussi été une grande leçon. Au cours de la simulation, alors que je pratiquais la posture de coach, j’ai « bloqué »,   cherchant  à tout prix un problème là où il n’y en avait pas. Dominic me présentait une situation qui ne correspondait pas schéma mental que je me faisais du déroulement et du contenu d’une rencontre caddy. Après m’être rendu compte que j’insistais inutilement, j’ai laissé Dominic continuer la rencontre, mais je n’étais plus dans l’écoute, j’étais contrarié. Non seulement je n’étais plus à son écoute, mais de surcroît, je n’étais pas capable de répondre au besoin simple qu’il avait ce jour-là (dans la simulation) qui faisait appel à des compétences techniques que je maîtrise sans difficultés.

Cela demande du courage de se confronter à des simulations même lorsqu’elles sont jouées dans un environnement sécurisant et sécurisé, mais la rétroaction des vingt paires d’yeux et d’oreilles sur ce qui s’est passé est très enrichissante, instructive et finalement réconfortante.

Depuis, je fais très attention à ce ‘piège’ dans chacune des rencontres que j’ai avec mes golfeurs en essayant de le détecter et de le désamorcer. À ce piège, mais aussi à tous ceux que nous identifions lors des autres simulations. J’essaie aussi de mettre en œuvre tous les ‘bons comportements’ que nous relevons et que nous valorisons lors des séances de feed-back.

Une simulation ne garantira jamais que je ne reproduise pas cette erreur ou que je n’en ferai pas d’autres, mais à chaque leçon apprise, un nouveau détecteur s’allume dans la case « situation de coaching» auquel je suis maintenant attentif. Rien ne remplace la réalité des rencontres et je ferai encore et toujours beaucoup d’erreurs, et ça n’est pas grave, mais il y a des chances pour que je fasse celles-là moins souvent.

Dans votre expérience et votre formation de coach, quelle est la place des simulations ? Qu’en retirez-vous ?

Une équipe peut-elle vivre sans ScrumMaster 'officiel'?

L’été dernier j’ai rejoint un projet qui avait démarré 15 mois auparavant. L’équipe chargée du développement était répartie entre 3 sites (1 à Montréal, 2 à Bordeaux). Peu après mon arrivée, il y a eu réorganisation des équipes, et dans notre équipe, nous avons proposé de ne pas avoir de ScrumMaster ‘officiel’. La question suivante se posait donc pour nous :

Une équipe Scrum peut-elle vivre sans ScrumMaster ‘officiel’?

Je dois dire tout de suite que nous n’avons pas eu le loisir de pousser très loin l’expérimentation car le projet a été interrompu environ 6 semaines après la réorganisation. Nous avons tout de même travaillé avec ce modèle pendant 2 itérations¹.

Cette équipe était composée de 3 personnes. Deux étaient présentes depuis longtemps : depuis le début pour l’un et depuis 10 mois pour l’autre. Puis il y avait moi, nouveau sur le projet. Le coéquipier leader naturel travaillait depuis plusieurs mois sur le module dont nous avions la charge. Il y avait une bonne cohésion, nous étions à l’aise avec Scrum et nous nous sentions en contrôle!

Nous tenions notre mêlée quotidienne² sans difficultés. Nous allions à tour de rôle à la mêlée des mêlées³ — cette pratique était déjà en place  bien avant la réorganisation. Nous faisions la maintenance du carnet de produit⁴ régulièrement avec le propriétaire de produit⁵. Nous aidions tous à l’organisation de l’équipe, même si une très grosse partie du travail était réalisée par le leader de l’équipe.

Voici les avantages obtenus lors de ce projet

• Nous nous sentions vraiment autonomes. Nous organisions nous même nos rencontres importantes (mêlée quotidienne, maintenance du carnet de produit, réunion avec les intervenants extérieurs).
• Nous étions beaucoup plus responsables. Lorsque quelque chose allait de travers, nous ne pouvions pas dire :  «Le ScrumMaster ne fait pas son boulot ».
• Nous avions une bonne flexibilité, mais ce point relève petut-être du fait que nous n’étions que trois.
• Contrairement à ce que j’ai vu à maintes reprises, personne dans l’équipe n’était perçu comme ’supérieur hiérarchique’.

Nous n’avons pas subi d’inconvénients, mais peut-être y en aurait-il eu à long terme.

Cependant je suis convaincu d’une chose : il y a un préalable. Cela peut fonctionner à la condition que l’équipe soit mature, tant sur le plan des personnes qui la compose que  sur le plan de la maîtrise des outils, du processus Scrum et de la communication. Je vous invite à lire, sur un thème similaire, le retour d’expérience d’Isabelle Therrien, où elle fait mention des dérives qui peuvent se produire. Dans les commentaires notamment, il est question de prendre du recul, ce qui n’est pas toujours simple quand on a la tête dans le code pour livrer de la valeur à longueur de journée.

Résumé en quelques lignes, le choix de ne pas avoir de ScrumMaster ‘officiel’ peut paraître rapide ou évident, mais tout ceci ne s’est pas décidé en un jour. De fait, même une fois en place, les questionnements suivants revenaient de façon récurrente dans nos conversations :

• S’il fait fonction de ScrumMaster, le leader doit-il prendre le titre et s’exposer?
• Ce rôle peut il être partagé, et dans ce cas, est-ce efficace?

Pour conclure, je dois dire que j’ai aimé cette expérience. Même si cela n’a pas duré bien longtemps, j’ai vu les prémices de quelque chose que je voulais vérifier depuis longtemps : « le rôle de ScrumMaster est un rôle temporaire, il a pour objectif de rendre son équipe capable de se passer de sa présence, et cela peut fonctionner ».

Avez-vous des retours d’expérience similaires à partager ?

In the post I didn’t have time to do this Martin said :

Life is as such as we accept more work and activities than we have time for, so claiming we didn’t have time for something seems like an understatement. In reality, what really happens is:

1. the individual didn’t want to do the work in the first place;

2. the person is procrastinating;

3. the person has difficulties in prioritizing their activities and cannot make a decision to determine which piece of work is more critical and should be completed first.

I used to get this excuse out of my hat too often in the past and that’s something I’m really trying to improve.

The tools I use are Getting Things Done known as GTD and popularized by David Allen and more recently the Pomodoro technique as they help me to manage my todos : to prioritize and to focus on doing.

The Pomodoro technique really helps to focus on the work that has to be done. Prioritize your tasks for the day, estimate, and do it focusing in small iterations : 25 minutes time-boxes + a 5 minutes break.

GTD is more big picture. But the most valuable impact from GTD is that all the work “to be done” is visible, and so that’s oblige me to make a decision : “Do I want to do it? Do I have to do it? Yes? No?”. If the answer is “NO”, I delegate it, or I delete it. No longer in my list, no longer in my mind! Sometimes I fold the idea in a “Someday/Maybe” place to delay it until I recover enough energy, or it becomes the things to do.

The last thing I did is to publicly communicate my occupations to my colleagues.

Learning to say “NO” is one of the hardest thing to do for me

How do you manage to eradicate the “I didn’t have time to do this” excuse from your vocabulary?

Comme prévu, la deuxième session nantaise autour de l’agilité s’est déroulée hier soir à la Halle 6 (rue de la Tour d’Auvergne)

Encore merci à

qui nous ont présenté leur expérience d’introduction de l’agilité au sein de leurs sociétés respectives.

Cette soirée a permis au groupe d’échanger sur la mise en place des pratiques agiles dans l’entreprise :

• développement itératif et incrémental
• contractualisation (visibilité et confiance dans l’engagement)
• radiateur d’information (transparence)
• backlog, burndown
• tests (confiance)

Tout cela demandant beaucoup de “courage”