Démarrage d’équipe – Focus interactions

Un exercice que je trouve déterminant et pourtant si souvent oublié dans le démarrage d’une équipe est la détermination du cadre d’interactions. J’entends par là cette conversation permettant à chacun de mieux appréhender l’autre au-delà de son rôle et de construire ensemble le nouveau visage de l’équipe en combinant leurs couleurs.

Utiliser un Team Canvas comme support de conversation aurait pu être une bonne base, mais j’ai décidé de faire autrement. C’est ce que je vous décris dans cet article !

Bonne lecture ! 😉

Contexte

La demande initiale vient du facilitateur de l’équipe qui souhaitait pouvoir participer dans le contenu plutôt que dans le cadre. Je trouvais cela plutôt pertinent dans le sens où c’était le bon moment pour faire connaissance et créer du lien.

En effet, cette équipe est toute nouvelle avec des personnes travaillant depuis quelques semaines au sein d’autres équipes pour monter sur les sujets et d’autres tout juste arrivées.

Pour rappel : Quelques jours avant l’intervention, j’apprends que le PO est en arrêt et ne pourra donc pas participer.

Conception

L’information sur la non-présence du PO est cruciale pour ma conception. 

En effet, une phrase que je garde de ma formation au Team Coaching est la suivante :

Ce n’est pas l’équipe qui crée l’objectif, c’est l’objectif qui crée l’équipe”.

– Global Team Coaching Institute

Le terme initial étant “purpose” en anglais pour plus de précisions.

Un démarrage d’équipe me semble alors particulièrement compliqué si l’on ne parle pas du contenu ou des objectifs à atteindre. Nous avons donc décidé de faire appel au Product Manager pendant une heure afin de donner les grandes directions dans l’attente du retour du PO. Il faudra donc s’adapter à ses dispos pour que cela reste cohérent dans le déroulé.

Cadre d’animation

Voici les informations avec lesquelles nous partons : 

1 intention principalecréer la dynamique d’équipe pour démarrer dans les meilleures conditions
1 intention secondaireapprendre à les connaître et construire la relation
2 fois 2 heures de temps2h00 le matin de 10h à 12h et 2 l’après-midi de 14h à 16h00
5 personnesLead dev, BA, 3 devs, Facilitateur
1 contraintePM dispo de 14h30 à 15h30

Pour construire, je commence par définir les objectifs à atteindre avant de décider du comment.

ObjectifsDescription
1J’aimerais qu’ils puissent apprendre à se découvrir au-delà de leur rôle dans l’équipe, et ce, rapidement.
2J’aimerais que l’équipe ait une vision de leurs objectifs (même avant l’intervention du PM)
3J’aimerais que l’équipe ait conscience de son écosystème
4J’aimerais que l’équipe définisse quelques règles d’interaction
5J’aimerais que l’équipe s’accorde sur une compréhension commune d’un mode de fonctionnement Agile / Scrum.

J’aurais donc 5 phases distinctes par lesquelles passer, rangées en ordre d’importance. En effet, au vu des contraintes de temps, je veux m’assurer que le maximum de valeur sera fait au début quitte à repousser les autres phases par la suite. Elles pourront être animées par le facilitateur au besoin.

Voyons ensuite les pistes de déroulement possibles.

PhaseObjectifDéroulé
1Se découvrir au-delà de son rôleLorsque je parle de se découvrir au-delà de son rôle, c’est simplement de connaître les personnes pour qui elles sont avant de ne voir que le titre et la fonction qu’elles représentent. 

Ayant un certain nombre de phases, je vais proposer quelque chose de simple et rapide pour commencer.

Chacun se présentera, sur post-it, avec son Prénom, sa Fonction / son Rôle, et une caractéristique individuelle.

Ce dernier élément aura pour objectif de créer plus de sensibilité à l’autre, dès le début.
2Avoir une vision partagée des objectifsDans cette partie, je vais simplement leur poser la question. Ce sont les résultats qui vont être intéressants à discuter.
3Prendre conscience de son écosystèmeOn réalisera ici un Stakeholder Mapping afin de visualiser les parties prenantes et les relations qui vont s’opérer avec l’équipe
4Définir quelques règles d’interactionDans cette partie, j’évoquerai surtout la notion de “sécurité psychologique” comme j’ai pu le faire dans cet article.

Cependant, au vu du temps à disposition, je pense simplement rester sur la première phase autour du besoin personnel.
5Partager un fonctionnement Agile / Scrum communL’idée ici est de parler un petit peu d’Agile mais surtout de se focaliser sur les événements Scrum qui vont rythmer la vie de l’équipe.

Les échanges seront plutôt autour des objectifs de chaque événement que sur les déroulés. En effet, ce sera le rôle du facilitateur de gérer la suite 🙂

Nous voilà parés pour lancer l’animation. Voyons ensemble ce qu’il s’est passé 🙂

Animation

Phase 1 : se connaître au-delà de notre rôle

Comme prévu, je demande à chacun de noter sur un post-it son prénom, sa fonction / son rôle et une caractéristique individuelle. J’ai intitulé ce dernier élément : « ce qu’il faut savoir de moi », sous-entendu « pour que cela se passe bien » 😛

Lorsque chaque personne a terminé, je les invite une par une à venir coller son post-it et à donner au groupe quelques éléments de détails. Voici les résultats ci-dessous :

Lorsque cela me paraissait intéressant, je me suis permis de questionner un peu plus longuement la personne. Cela a l’intérêt de générer plus d’échanges et d’interaction entre les participants. Sans surprise, c’est sur la caractéristique que je me suis appuyé 😉

Quelques exemples :

CaractéristiqueQuestions complémentairesPourquoi ?
J’aime aider– Qu’apprécies-tu dans le fait d’aider les autres ?
– Que se passe t-il si l’on refuse ton aide ?
– Est-ce que tu attends cela des autres également ?
Donner du sens aux autres sur l’importance de cette caractéristique pour la personne, par l’introspection

Expliciter les comportements attendus et leurs impacts
Fan de Japon (Manga, Anime…)– Y es-tu déjà allé ?
– Quels sont les derniers Mangas / Animes que tu as vus ?
– Aurais-tu une recommandation à faire ?
Créer du lien, des connexions. Une personne qui parle de ce qu’elle aime aide à développer un climat de partage et d’ouverture.
J’aime le dev bien fait– Qu’entends-tu par « bien fait » ?
– Lorsque ce n’est pas « bien fait », qu’est-ce qui se passe ?
– Est-ce qu’à vouloir trop bien faire, il t’arrive d’en oublier les contraintes de temps ?
Expliciter les besoins

Prendre conscience des limites et les porter à l’attention de l’équipe
J’aime le partage– Sur quels sujets aimes-tu partager ?
– En quoi est-ce important pour toi ?
– Sous quelle forme aimes-tu partager ?
Ouvrir la voie au collaboratif et au collectif

Note : les débuts de réunion peuvent être un peu silencieux voire timides, intervenir de la sorte permet de donner un peu plus de couleurs aux conversations. Les personnes s’ouvrent alors plus facilement si tant est que l’on crée le bon environnement. Ayant le mandat sur le cadre, je peux plus facilement me le permettre et cela me permet de créer cette ambiance de curiosité et de non jugement que j’affectionne tout particulièrement ! 🙂

Phase 2 : Objectifs de l’équipe

Dans cette deuxième phase, je questionne de nouveau les participants :

Quels sont les objectifs de votre équipe ? Pensez bien aux impacts que vous souhaitez générer et donc pour qui 🙂

Voici les réponses qui on été évoquées :

Sans rentrer dans les détails de chacune, il m’apparaît toujours intéressant de voir la diversité de réponses par rapport à la même question. Cela dépend souvent du positionnement de chaque personne par rapport à son rôle, son métier et sa contribution perçue à l’atteinte de l’objectif.

Le coeur de l’exercice est donc dans la facilitation des échanges. L’idée ici est bien de clarifier l’attendu final et les impacts de la réalisation du projet donné avec une première vision des utilisateurs.

Note : Le PM devait apporter plus de précisions par la suite mais je voulais déjà jauger où l’équipe se situait sur le sujet.

Cela amène alors naturellement à la phase 3 où l’on va chercher à clarifier l’écosystème permettant à l’équipe de réaliser ses objectifs.

Phase 3 : Stakeholder Mapping

Dans cette partie, on va réaliser un Stakeholder Mapping. L’idée générale est de modéliser les différentes parties prenantes ainsi que leurs interactions en termes de flux d’information.

Nous le construisons donc ensemble au fur et à mesure pour finalement aboutir au résultat suivant :

Ce fut une bonne occasion de (re)présenter l’organisation aux membres de l’équipe, tout particulièrement les nouveaux. De nombreuses questions ont émergé et ont fait évoluer la cartographie au fur et à mesure. C’est bon signe, l’équipe travaille déjà ensemble pour clarifier les choses !

Phase 4 : Quelques règles d’interaction

Dans cette phase, j’ai voulu aborder la notion de sécurité psychologique qui me semble être finalement trop peu connue des équipes. C’était d’ailleurs effectivement le cas pour cette équipe.

Après avoir défini rapidement ce qu’était la sécurité psychologique, j’ai invité chacun à réfléchir sur ses besoins pour se sentir en sécurité et pouvoir s’exprimer librement au sein du collectif. Chacun est ensuite passé au fur et à mesure de la même manière que pour la phase 1.

Il est intéressant de voir qu’après toutes les phases précédentes ont contribuer à créer une ambiance conviviale et ouverte. Cela a grandement aidé à ce que chacun puisse exprimer sa part de vulnérabilité de manière sereine.

Note : Je n’ai pas tellement eu besoin de questionner ce coup-ci, les membres d’équipe le faisant plus naturellement eux-mêmes. J’ai surtout demandé des précisions lorsque les mêmes termes étaient utilisés pour bien comprendre ce qui était entendu derrière 🙂

En terme de timing, nous avons réussi à terminer cette phase avant le déjeuner. C’est pour dire que les consignes étant simples et claires, cela peut aller assez vite tout en étant riche en conversations.

Interlude : Partage PM

De retour de déjeuner, le PM étant disponible un peu plus tôt, nous en avons profité pour qu’il partage la vision du projet. Il a pu ainsi faire plus ample connaissance avec l’équipe et répondre à leurs questions.

Nous enchaînons par la suite avec notre dernière phase 🙂

Phase 5.1 : Agile

Dans cette dernière phase, j’ai souhaité faire une passe rapide sur l’Agilité. Voici les quelques messages que j’ai choisi de transmettre.

Agile ≠ Scrum

Pour cela, j’utilise simplement le Golden Circle de Simon Sinek appliqué au sujet de l’Agilité. En effet, j’apprécie le côté visuel de cette représentation qui permet facilement d’ouvrir les échanges.

J’évoque donc le Manifeste Agile et sa description de 4 valeurs et 12 principes fondamentaux.

En parlant des valeurs, je partage le résumé qu’Alistair Cockburn avait fait il y a de cela quelques années lors d’un Scrum Day (oh oui ça date !) :

People over Process

Le message ici est que l’Agilité n’est pas qu’un ensemble de pratiques mais qu’elle a vocation à aider les personnes à mieux interagir ensemble pour atteindre leurs objectifs.

D’ailleurs, avant de rentrer dans les pratiques, j’ai voulu faire un passage sur 1 des 12 principes :

Un logiciel opérationnel est la principale mesure d’avancement

J’apprécie tout particulièrement ce principe car il questionne plusieurs sujets notables : qu’entend-on par opérationnel et mesure d’avancement ?

Opérationnel signifie fonctionnel et répondant au besoin client

Cela implique donc 2 niveaux de feedbacks :

  • De l’équipe pour s’assurer que la solution fonctionne correctement
  • Du client pour s’assurer que l’on réponde bien à son besoin

C’est pourquoi on cherche à construire des petits morceaux de solution compréhensibles par le client. Il pourra ainsi nous dire si cela correspond à son besoin. Cette relation équipe-client est donc essentielle à entretenir pour s’assurer que l’on va dans la bonne direction. C’est ce que l’on met derrière mesure d’avancement.

Stop Starting, Start Finishing

En effet, on considère avoir avancé si l’on a pu fournir un élément de valeur utilisable par le client. Avoir quelque chose « en cours » n’a pas de valeur en soi. C’est pourquoi on cherche d’abord à terminer ce sur quoi on s’est engagé plutôt que de commencer de nouveaux éléments.

Phase 5.2 : Événements Scrum

Après avoir introduit quelques messages clés d’Agilité, nous nous sommes attelés à discuter des 4 événements Scrum : le Sprint Planning, le Daily Scrum, la Sprint Review et la Sprint Retrospective.

J’ai invité chaque personne à noter sur post-it le ou les objectifs de chaque événement. Un post-it par événement bien évidemment.

On aurait pu aussi simplement présenter les événements de manière descendante. C’est vrai. Cependant, ce qui m’intéressait ici n’était pas de partager la théorie mais plutôt que le groupe co-crée le sens de ces éléments ensemble. Constructionisme Social quand tu nous tiens 🙂

En effet, il est rare aujourd’hui que les personnes n’aient pas du tout entendu parlé des événements Scrum dans le monde IT. Par contre, ils n’ont pas toujours la même intention ni mise en oeuvre.

Voici les résultats :

On peut voir à nouveau la différence dans les réponses des participants :

  • Certains répondent par un processus : « Parler de ce qu’on a fait la veille et les difficultés rencontrées« , « Parler de ce qui a marché et ce qui n’a pas marché« , ‘Découper les tâches, les chiffrer et les livrer sur 2 ou 3 semaines« 
  • D’autres par des livrables : « Infos« , « Des actions d’amélioration« , « Liste de tâches à faire« 

C’est dans ce cas où je recentre les échanges sur les objectifs des différents événements. Le coeur de mon action est donc dans la facilitation plutôt que dans la formation ou le coaching. L’idée est à nouveau qu’ils repartent avec une base commune sur laquelle démarrer quitte à la faire évoluer dans le temps.

Cependant, il me paraissait important d’ouvrir la porte à d’autres perspectives pour les personnes qui n’avaient qu’une compréhension « pratique » de Scrum.

En terme de timing, nous terminons juste à temps pour aller prendre un café ensemble 🙂

Conclusion

Dans cette animation, j’ai opté pour la simplicité en me focalisant principalement sur les interactions des membres de l’équipe entre eux. En effet, il n’est pas toujours nécessaire de construire un atelier compliqué pour obtenir un résultat. Un intention claire, quelques questions, de la facilitation et un support pour structurer les échanges peuvent suffire 🙂

Partager

Olivier MY

Olivier MY

Issu d'un cursus ingénieur, je me suis vite rendu compte que mes appétences et compétences tournaient plus autour de l'humain que de la technique. Je suis alors devenu Coach Agile et Coach Professionnel car j'ai toujours voulu contribuer à rendre le monde meilleur. J'accompagne aujourd'hui des individus, des équipes et des organisations vers une meilleure compréhension d'eux-mêmes afin de bâtir ensemble le futur qui leur correspond.

Commentaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Articles récents

Quelle taille de ticket pour mon Kanban ?

Une question récurrente lorsque l’on parle de flux est de connaître la taille d’un élément de travail. En effet, on part du principe que plus …

LIRE PLUS

L’origine fascinante du terme « Cérémonie Scrum »

Voici un des grands sujets de la communauté Agile concernant Scrum : parle-t-on de cérémonies ou d’événements ? Dans le Scrum Guide, on ne retrouve …

LIRE PLUS

Featureban : un atelier de simulation Kanban

Il existe un certain nombre d’ateliers pour illustrer la méthode Kanban. Cependant, la plupart d’entre-eux sont longs (au moins 2h) et nécessitent un matériel spécifique …

LIRE PLUS

Le Jeu des Prénoms

Vous est-il déjà arrivé de vous sentir noyé(e) par les demandes, sans en voir le bout, et ce malgré tous vos efforts ? Vous n’êtes …

LIRE PLUS

Individual Map : apprendre à se connaître en quelques questions

Dans le cadre de mes accompagnements d’équipe, je cherche constamment à développer les relations entre personnes. Cela passe notamment par une meilleure connaissance interpersonnelle. Un …

LIRE PLUS

Stakeholder Mapping : visualiser l’écosystème pour mieux le gérer

Dans la plupart des écosystèmes dans lesquels j’ai pu intervenir, les dépendances entre équipes et services ont été de grandes sources de difficultés pour la …

LIRE PLUS
Retour haut de page

Prenons contact