Chez BENEXT, le Forum Ouvert est ancré dans notre ADN. On en faisait il y a plus de six ans quand j’ai rejoint l’aventure et on en fait encore aujourd’hui - jeudi prochain, j’anime la journée de la communauté tech et la matinée sera structurée en Forum Ouvert. Alors, pourquoi j’aime tant cet exercice ?

C’est enrichissant. Les sujets sont nombreux et variés, les participants aussi. Tout peut arriver. Quand on participe à un groupe de discussion, on peut donner et recevoir. On y va pour apprendre et pour contribuer. Ce n’est pas seulement de la descente d’information. On ressort plus grand de chaque discussion.

C’est libre et auto-organisé. Il y a un cadre simple, éventuellement une thématique et… c’est tout. Le programme se créé de lui-même avec tous les participants lors de la place de marché. Les participants et groupes de discussions sont autonomes. Chacun fait ce qu’il veut et va où il veut. Chacun s’organise comme il le souhaite, anime comme il l’entend.

C’est spontané. Il y a de l’émergence et de la créativité. Le Forum Ouvert ne requiert pas de préparation en amont pour les participants. La place de marché est dynamique, n’importe qui peut proposer n’importe quoi. Des créneaux et des lieux peuvent même s’ajouter ou se modifier. Encore une fois, tout peut arriver et c’est tant mieux. On laisse libre cour à la créativité.

C’est inclusif. Il y a de la place pour tout le monde. Pour toutes les personnalités. Pour tous les niveaux d’expériences. Un débutant comme un expert chevronné. Pour tous les métiers. Parfois, on mélange des communautés qui se ressemblent, parfois on mélange toute l’entreprise - et on y retrouve vraiment tout type de profil (des RHs, des développeurs, des designers, des coachs, des products manager, …).

C’est vivant. Les personnes discutent, réfléchissent, rient, bougent, dessinent, fabriquent, se déplacent entre les salles. Le Forum Ouvert vit à travers ses participants.

C’est adaptable. On peut organiser un Forum Ouvert avec quelques personnes comme plusieurs milliers. On peut le faire sur quelques heures comme sur quelques jours. On peut le faire dans tout type de lieux et salles.

Organiser un Forum Ouvert

A l’instar des participants qui n’ont pas besoin de se préparer en amont, l’organisation d’un Forum Ouvert demande peu d’effort. Une partie de la préparation réside dans ces quelques questions :

• Quel est le thème ? Est-ce totalement libre ? Autour d’un domaine (le développement logiciel, le product management, …) ? Ou bien sur une problématique ?
• Quelle est la durée totale du Forum Ouvert ? Est-ce sur une journée entière ? Une demie-journée ? Quelques heures ?
• Quelle est la durée de chaque créneau ? 30, 45, 60 minutes ?
• Quels sont les lieux et salles à notre disposition ?

L’autre partie sera logistique. Toujours léger : avoir un tableau blanc ou du papier craft pour la place de marché, des post-its et des feutres, préparer les lieux de discussions. Sans oublier d’envoyer les invitations. À noter que plus il y aura de monde et de profils différents, plus ce sera riche.

Le jour J, on commence par réunir tout le monde devant le tableau de la place de marché. Une personne y explique le cadre et les règles, puis l’auto-organisation prends le relai. Les participants peuvent remplir à tour de rôle le tableau avec leurs propositions. Prévoir une quinzaine de minutes.

Lorsque le tableau est rempli ou qu’il n’y a plus de proposition, le premier créneau peut commencer. Les participants se dispersent là où ils veulent. A la fin de chaque créneau, ils se rejoignent à nouveau devant la place de marché pour faire une courte restitution. Une personne de chaque groupe partage brièvement aux autres ce qu’il s’est passé. Et ainsi de suite jusqu’à la fin.

Place de marché

La place de marché est le moment où chaque participant peut contribuer à créer le programme du Forum Ouvert. J’insiste sur ce point : n’importe qui peut proposer. C’est différent d’un CFP (Call for paper, appel à sujet) qu’on peut retrouver dans une conférence où ce sont les sachants qui postulent.

Dans la place de marché d’un Forum Ouvert, on peut avoir plusieurs postures :

• Je suis sachant, expert sur un sujet. Je veux partager et transmettre mes connaissances. Je veux faire un retour d’expérience. Je cherche des gens qui voudront en apprendre plus.
• Je suis novice sur un sujet. Je veux apprendre. Je cherche des sachants et éventuellement d’autres personnes qui veulent apprendre.
• Je veux discuter sur un sujet, ouvrir un débat. Je cherche d’autres personnes pour échanger.
• J’ai un problème. Je cherche de l’aide.

Je trouve ça extrêmement puissant. Tout le monde est embarqué et peut apporter sa pierre. Chacun peut avoir un impact. A tour de rôle, les participants peuvent venir présenter en 30 secondes le sujet devant les autres, prendre un post-it pour écrire le sujet et le coller sur le tableau en choisissant un lieu et un créneau horaire. C’est un moment d’écoute, tout le monde n’y va pas en même temps. Une personne à la fois.

En fonction du nombre de salles, de la durée du Forum Ouvert et de la durée des créneaux, on obtient un tableau, un quadrillage qui associe lieux et créneaux horaire. Chaque case peut accueillir un sujet de discussion. Par exemple, proposer 3 créneaux de 45 minutes sur 4 salles permet d’avoir jusqu’à 12 sujets.

On recueille les propositions jusqu’à ce qu’il n’y ait plus de place ou plus d’idée. Mais on peut aussi hacker le format en ajoutant une salle, en prenant un double créneau, etc. C’est libre et auto-organisé.

Idéalement, le tableau de la place de marché est visible et central. On veut que les participants passent devant régulièrement, le voient, et puissent y accéder facilement.

Le cadre

Le Forum Ouvert repose sur un cadre simple et de la liberté. On y trouve quatre principes, une loi et deux animaux totem. Ce sont des guides pour tous les participants, ils viennent renforcer l’auto-organisation. Certains principes peuvent sonner comme des évidences, mais ils sont essentiels au bon fonctionnement du Forum Ouvert.

Quatre principes

Les personnes qui sont là sont les bonnes personnes. Ce sont les personnes qui ont choisi de venir, ce sont les personnes qui sont motivées par le sujet. Un groupe impliqué et enthousiaste fera des merveilles. Ces personnes sont présentes, et ce sont les seules à être présentes. On se concentre sur elles. On ne se soucie pas de ceux qui ne sont pas là, du nombre, ni même de l’expert qui pourrait être là.

Ce qui se passe est la meilleure chose qui pouvait se passer. Ou dit autrement, ce qui arrive est la seule chose qui pouvait arriver. C’est une recette unique avec les participants, le lieu, le sujet, l’heure. Ce qui en sortira sera le seul résultat possible. Laissez-vous surprendre positivement.

Ça commence quand ça commence. Ça peut démarrer à l’heure, comme ça peut démarrer en retard, mais ce sera le bon moment. Aussi, l’inspiration et la créativité arrivent en leur temps, ça ne se commande pas.

Quand c’est fini, c’est fini. Lorsque l’on arrive au bout, c’est terminé. Inutile de forcer, de consacrer plus de temps que nécessaire. C’est parfaitement ok d’arrêter avant la fin du délai prévu.

Une loi

La loi des deux pieds donne une responsabilité aux participants : si je n’apporte rien et qu’on ne m’apporte rien, alors je dois prendre mes deux pieds et changer de lieu. Le respect de cette règle est important pour garantir le succès du Forum Ouvert. La réussite est dans les mains des participants. On va dans un lieu pour contribuer et apprendre. Les échanges et les transmissions seront d’autant plus riches.

On part discrètement sans interrompre, en faisant éventuellement un signe. Et c’est OK vis-à-vis des autres participants. Il n’y a pas de jugement. Il n’y a pas de mal à chercher. Les participants restants continuent leurs discussions.

Deux animaux totems

Les animaux totems représentent les attitudes que l’on peut adopter durant un Forum Ouvert. Ce sont des images. Elles ont un lien fort avec la loi des deux pieds.

Les papillons ne sont dans aucun lieu. Ils vont prendre une pause. Ils vont réfléchir. Ils vont papillonner dans les alentours.

Les abeilles vont butiner dans plusieurs lieux. Elles vont circuler de lieu en lieu pour se nourrir et pour faire circuler des idées. Elles pollinisent.

On le voit, la place de marché ouverte et le cadre, avec ses principes, viennent garantir une certaine liberté. De l’auto-organisation pour chaque participant, individuellement, et pour chaque groupe. Il y a de l’émergence. On se laisse surprendre par les sujets et par les discussions. C’est spontané, c’est enrichissant, c’est vivant.

C’est un atelier qui peut s’utiliser dans n’importe quel domaine et pas seulement dans le monde du logiciel (même si son créateur, Alberto Brandolini, est un développeur). On pourrait modéliser le fonctionnement d’une équipe de RHs tout comme le parcours d’achat d’une application.

Les événements forment la colonne vertébrale de L’Event Storming. On parle de ce qu’il se passe dans le processus, dans le système, sur une ligne de temps. On peut le raconter, c’est une histoire. Le storytelling est un aspect très puissant de cet atelier.

C’est en plus modulable : on peut ajouter différentes étapes qui feront naître de nouvelles conversations selon le besoin. On pourrait par exemple introduire les acteurs qui agissent sur le système ou les dépendances externes. On peut s’adapter en fonction du niveau d’abstraction que l’on souhaite avoir, d’une vision très macro à une vision très micro sur un bout de logiciel.

Pour autant, l’Event Storming reste simple, ce qui le rend d’autant plus efficace - on va en retirer quelque chose à la fin. Le cadre est léger. C’est très libre, voire parfois chaotique. Et c’est très bien. Ça donne de l’espace aux participants pour faire émerger une compréhension commune.

Quand déclencher un Event Storming ?

Dès lors qu’il y a de l’incompréhension ou un besoin de s’accorder. La force de l’Event Storming est de rassembler de nombreuses personnes et de tout mettre à plat sur un mur. On va rendre l’implicite explicite et harmoniser les modèles mentaux de chacun.

Quelques autres signaux intéressants pour déclencher : on a trop de bugs, on a des zones de floues, on veut s’aligner avec un existant, on veut cartographier de la connaissance.

Plus axé conception logiciel, l’Event Storming aura également son utilité associé au Domain-Driven Design lorsque l’on souhaite découvrir des Bounded Contexts ou des agrégats, ou associé à de l’Event Sourcing pour identifier les événements.

Une animation d’Event Storming

Il y a plusieurs recettes pour animer un Event Storming. Alberto compare l’atelier à une pizza. Il y a une base avec de la tomate et de la mozza (notre ligne de temps avec nos événements). Et ensuite, on y ajoute différents ingrédients au choix (des acteurs, des commandes, des données, des règles, …), sauf quelques exceptions (ni ananas, ni table de base de données :p). Je parle de tous ces éléments et leurs interactions dans cet article.

Selon le besoin, on va donc ajouter des étapes supplémentaires. En général, on veut au moins voir qui fait quoi. On veut identifier les acteurs et les systèmes externes qui nous ajoutent des contraintes, ainsi que les problèmes.

Pour cette introduction, on composera avec les événements ainsi que les commandes, acteurs, données et dépendances. C’est une bonne entrée en la matière que j’ai vu avec Marion Lecerf et Pablo Pernot lors d’un atelier pendant la conférence School of PO ; on obtient rapidement une cartographie intéressante du système.

Libre à vous d’adapter comme vous le souhaitez. On peut ajouter ou supprimer des étapes, en rassembler certaines en une seule étape, être plus macro ou plus micro. C’est très modulable. J’y reviendrais dans un second temps.

Préparation

En amont de l’atelier, on prendra soin d’inviter toutes les personnes qui ont un lien avec ce que l’on veut faire. Si on prend l’exemple d’un logiciel, on pourrait y inviter des développeurs, des POs, des experts du métier, des collaborateurs d’une équipe externe, etc. Toute personne qui peut contribuer est la bienvenue - on veut voir l’image dans son ensemble, on veut éclaircir des zones d’ombre, il faut qu’il y ait tous les acteurs.

Second point, la salle et le matériel. Il faut réserver un grand espace, avec de grands murs. On éloignera le mobilier qui peut gêner, et on mettra à disposition une infinité de stylos et de post-its avec les bonnes couleurs. Prévoir plusieurs mètres de papier craft idéalement pour permettre d’écrire et dessiner directement dessus. Possiblement du scotch ou des ficelles. Ça fonctionne aussi à distance sur un outil comme Miro.

Les événements

Sur une ligne de temps que l’on aura tracé, les participants vont s’atteler à positionner ensemble tous les événements qui composent le processus. On construit la colonne vertébrale. C’est ce qu’il se passe dans notre système. On peut commencer par délimiter le début et la fin en plaçant le premier événement et le dernier événement du processus pour borner.

On utilise des post-its oranges. Les événements sont décrits par un verbe au participe passé. « Facture générée », « Commande livrée ». C’est quelque chose qui a eu lieu. C’est très important. On veut forcer les participants à penser avec des actions achevées, des changements d’état, des choses qui peuvent agir comme un déclencheur pour une autre action. Les événements doivent être parlant pour les experts métiers et ça tombe bien, ils sont censés être dans la pièce avec nous.

Si on a du conditionnel, on peut faire deux branches. Et si on a trop de branches, on se dit qu’il faut les mettre de côté et faire un atelier dédié afin de se concentrer sur notre branche principale. On veut se concentrer sur notre cas nominal.

On veillera à exprimer tout ce qui vient via des post-its. On veut voir émerger l’ensemble du modèle. On discutera après. Ça peut sembler chaotique mais c’est ce que l’on veut. Lors de l’atelier avec Pablo, il indiquait qu’il poussait au chaos : si ce n’est pas assez bordélique, c’est peut-être qu’il n’y a pas les bonnes personnes ou qu’il y a trop de limites.

On peut marquer les désaccords, les questions, les risques, ça fait partie du modèle. On utilise des post-its roses foncés / rouges pour ces points d’attention (les Hot Spots). Alberto n’hésite pas à marquer tout ce qui s’éloigne du scénario nominal pour rester concentré. Ce seront des éléments à creuser plus tard. « Attention RGPD », « Que fait X ? », « Risque de fraude de paiement ». On peut les positionner en hauteur pour surplomber, ou directement à l’endroit où ça fait sens, au choix.

Cette première étape peut prendre du temps, c’est normal. Les événements forment le cœur du processus. Lorsqu’on arrive à la fin, on demande à une personne de raconter l’histoire qui est modélisée. Le storytelling fait son apparition, les gens aiment écouter des histoires. On en profite pour peaufiner et clarifier le modèle si besoin. Peut-être qu’il manque une précision à un moment. Peut-être qu’il reste une zone de flou.

Les commandes

Dans notre seconde étape, on va positionner les commandes. C’est ce qui déclenche un événement, souvent une conséquence d’une action utilisateur, une prise de décision, ou d’un système externe.

On utilise des post-its bleus. La commande est décrite avec un verbe à l’infinitif. « Ajouter au panier ». Elle est placée devant l’événement sur la ligne de temps.

Les commandes peuvent être utiles pour faire émerger du bordel, surtout sur un système existant, pour aligner les connaissances. On peut trouver que la commande et l’événement sont redondants. Avec la commande, on parle de l’action réalisée par un acteur, qui sera le déclencheur d’un ou plusieurs événements. Il n’y a pas forcément une commande sur chaque événement. Avec les commandes, on se projette également un peu dans le code.

Les acteurs

Troisième étape, on positionne les acteurs. Ce sont eux qui déclenchent les commandes. Ce peut être un utilisateur ou une partie d’un logiciel. On utilise des post-its jaunes et on y marque le nom de l’acteur. « Le client », « Le livreur », « Le système Y ». L’acteur est placé sur la commande, légèrement sur la gauche.

Les données

On arrive à la quatrième étape où l’on positionne les données. En anglais Read Model. Il y a une nuance importante ici. On va parler des données que l’on affiche et qui vont aider les acteurs à prendre des décisions. On ne parle pas des données que l’on écrit (écriture dans une base, un registre…), ces informations sont déjà indiquées dans les commandes comme « Ajouter (l’article) au panier ».

On utilise des post-its verts. On y écrit les données principales. « Nom, Prénom, Email ». On se limite pour mettre en valeur ce qui compte réellement. Le post-it est placé avant l’acteur.

Ne pas hésiter à se faire une session de storytelling pour s’assurer que tout va bien, et qu’on est aligné. On peut faire des sous-groupes. Est-ce qu’on est tous d’accord ? Est-ce clair pour tout le monde ? On peut commencer à préciser. Précis mais pas exhaustif, sinon on n’en fini pas. On met davantage au propre.

Les systèmes externes

Pour notre cinquième étape, on positionnera les systèmes externes. Ce sont les dépendances. On veut voir apparaître les adhérences auxquels est soumis le système, ce qui le contraint. On utilise des post-its rose clair. « Le fournisseur », « Service Z ».

On peut à nouveau reprendre le storytelling et raconter les événements afin de s’assurer que tout est représenté comme dans la vraie vie.

Quelques détails et astuces

Ici comme ailleurs, vous verrez qu’on associe une couleur à chaque élément de l’Event Storming. Respecter ce code couleur a son importance. On veut faciliter la lecture et la compréhension lors de l’atelier, et on veut s’y retrouver facilement si ce n’est pas notre premier Event Storming (on s’enlève la charge mentale de devoir réapprendre un autre code couleur). En voici un rappel :

• Acteur en jaune,
• Agrégat en jaune clair,
• Commande en bleu,
• Données en vert,
• Événement en orange,
• Point d’attention en rose foncé / rouge,
• Règle métier en violet,
• Système externe en rose clair.

On pourrait dire la même chose de la mise en page. Si tout le monde adopte une façon unique de présenter les post-its, on améliore la lisibilité. Une bonne pratique est d’afficher le modèle des différents post-its sur le mur.

Veillez à bien espacer les post-its entre eux pour faciliter l’ajout de nouveaux post-its au fil des étapes. D’ailleurs, un classique quand on joue avec des post-its, écrivez en majuscules, en gros, et soyez concis.

Dernière précision. On peut toujours mettre un événement, un acteur ou tout autre type de post-it même si on est passé à l’étape suivante. C’est toujours le bon moment d’ajouter de l’information.

Avec quoi on repart ?

On obtient de la visibilité. L’ensemble du processus, du système est rendu visible. Il n’y a plus de zones d’ombre - ou s’il y en a, elles sont explicitement révélées. Les problèmes et les questions sont identifiés. On va pouvoir avancer sur ces sujets.

On obtient de la compréhension. On peut avoir des prises de conscience comme “je ne pensais pas que je te créais des problèmes là-bas en faisant ça” ou “je ne savais pas que tu faisais ceci”. Les participants comprennent ce qu’il se passe chez eux et chez les autres, on casse les silos. On va améliorer la collaboration.

On obtient de l’alignement. On s’est mis d’accord tous ensemble sur le modèle, sur les problèmes. Continuons d’avancer ensemble.

La suite est très modulable, tout comme l’est l’atelier. On peut imaginer un tas de choses pour travailler sur le processus :

• Voter pour le problème principal, qui pourrait devenir la priorité numéro une.
• Mettre en lumière les zones à améliorer, et travailler dessus avec le temps.
• Identifier où il peut manquer des compétences.
• Regarder le niveau de qualité dans les zones les plus importantes pour le métier.
• Travailler sur les dépendances et goulots d’étranglement.
• Simplifier le processus.
• Etc.

Pour aller plus loin, Les éléments d’un Event Storming et leurs interactions.

Merci Marion Lecerf et Pablo Pernot pour les divers échanges, et Yannick Grenzinger qui avait initié mon équipe l’année dernière :)

C’était lors d’un beCom début octobre - un événement à benext qui regroupe toute une communauté sur l’après-midi. Les participants étaient demandeur d’approfondir un sujet, notamment avec de la pratique. On a proposé avec Cédric d’animer un Mob-Programming.

J’aime beaucoup faire du Mob-Programming. C’est un excellent moment pour partager, apprendre, et explorer avec plusieurs personnes. On s’est dit que ce serait un très bon moyen pour que le groupe puisse apprendre activement. Que les plus sachant transmettent. Que les plus néophytes découvrent et essayent. Que tout le monde se challenge à son niveau.

Cédric restait au clavier (covid oblige) pour retranscrire toutes les volontés du groupe. De mon côté, je facilitais. Nous étions aussi là en conseil pour accompagner le groupe lorsqu’il y avait besoin.

Trop de libertés, peu d’initiatives

On a démarré avec un format très libre. Tout le monde pouvait participer, proposer et faire avancer à tout instant. Résultat, de nombreux silences et non un brouhaha. Une seule personne participait activement et deux autres de manière sporadique (oui, je suis en manque de Kaamelott). Le reste du groupe était totalement passif.

Un début pas très dynamique, probablement ennuyant pour certains participants. Un début qui me demandait également beaucoup d’énergie pour la facilitation, pour insuffler de la vie, faire participer, faire questionner, etc.

Avec le recul, je me dis que l’on n’a pas assez pensé au public ciblé en amont. Un public composé majoritairement de jeunes développeurs et non habitué à des pratiques tel que le Mob-Programming. Avoir trop de liberté était contre-productif, cela freinait les participants. Et avec 10 personnes, c’était un grand groupe. Il fallait un cadre plus fort.

Des binômes et de l’action

Au bout d’une heure, j’ai proposé de faire un break pour s’aérer l’esprit. On a échangé brièvement avec Cédric et on était du même avis, c’était difficile. On a repris avec une nouvelle formule.

On a désigné deux personnes au hasard. Celles-ci héritèrent du rôle de leader : elles devaient faire des choix, réfléchir à voix haute et indiquer comment avancer à Cédric (au clavier). Toutes les dix minutes, on tournait avec les deux personnes à côté. Et ainsi de suite. Le reste du groupe pouvait bien entendu participer en même temps, mais c’est le binôme qui était responsable de faire avancer.

Rapidement, le Mob-Programming est devenu vivant. Les échanges au sein du binôme étaient intéressants, il y a avait de l’interaction entre les personnes, et le groupe avançait bien. L’ensemble du groupe s’est mis à participer. Les personnes étaient avec nous. Lors du debrief de fin de journée, les retours étaient très positif sur le passage en binômes.

J’avais également moins d’effort à fournir sur la facilitation. Inconsciemment, j’essayais de combler cette absence de cadre en première partie. Le groupe gagnait en autonomie et je pouvais me concentrer sur d’autres choses.

Assigner des rôles et les faire tourner

En assignant des rôles, on a proposé un cadre dans lequel les participants évoluaient. Ce rôle les responsabilisait. Le rôle les poussait à l’action et à la réflexion. Au sein d’un grand groupe, cela évite l’effet “quelqu’un le fera à ma place”.

Faire tourner ces rôles permet de rendre tout le monde actif à un moment. Les participants étaient davantage présents, et le fait de minuter donnait un rythme. Le groupe arrête de se reposer sur une seule personne très active, et celle-ci laisse la main.

Je repense aux sessions de Mob-Prgramming que je fais avec des personnes plus chevronés, en format assez libre : il y a aussi des moments où l’on désigne une personne qui prend le lead. Et des moments où l’on change. Ca fonctionne bien.

Tout ceci me fait dire qu’avoir des rôles tournant, ou au moins un lead tournant au sein du groupe est une composante importante du Mob-Programming. La méthode du Driver & Navigator va d’ailleurs dans ce sens.

Récemment, j’ai préparé et animé un atelier pour faire émerger des bonnes pratiques dans une expertise iOS. Celle-ci regroupe 9 développeurs dispersés dans plusieurs feature teams. Trois de ces équipes travaillent sur la même grande base de code de l’application, et la quatrième est isolée sur un SDK.

Les bonnes pratiques font parti de ces sujets sensibles qui peuvent vite déclencher des débats philosophiques ou de forts désaccords. Plus le nombre de personne est élevé, plus cette probabilité augmente. En réunissant 9 développeurs d’équipes différentes, il me fallait structurer les échanges pour limiter cela. Ces feature teams n’avaient pas forcément les mêmes besoins ni les mêmes points de douleurs, mais il existait cependant des dépendances dans le code entre elles.

Il y avait également l’envie de s’améliorer et d’avancer ensemble. J’ai alors centré l’objectif de l’atelier là-dessus. Faire émerger ensemble les premières bonnes pratiques de l’expertise. Puis j’ai préparé le format, divisé en trois principales phases : l’idéation, la priorisation et les discussions. Voici des explications sur ce format, ainsi que des retours sur l’atelier.

Déroulé de l’atelier 📜

Initialement prévu pour être animé en physique, l’instauration d’un confinement suite au Covid-19 a apporté une contrainte supplémentaire : avoir tous les participants à distance. Pour m’adapter, je me suis appuyé sur draft.io comme support de présentation et d’interactions. Microsoft Teams, l’application de communication en place dans les équipes, servit à créer une conférence audio. Je compléterais avec des indications spécifiques pour draft.io.

Cadre

Pour lancer l’atelier, j’aime bien présenter un cadre et un objectif. Si l’on dévie, il est plus facile de se recentrer sur le sujet et de rappeler à l’ordre car on s’est mis d’accord ensemble sur les règles. En se référant au cadre, on évite aussi que la personne se sente jugée. Il ne s’agit pas d’elle, mais du cadre. Voici celui proposé pour cet atelier :

• Faire preuve d’écoute et laisser la parole aux autres.
• Une seule personne parle, pas de discussions multiples.
• Couper son micro si on ne parle pas.
• Se concentrer sur l’objectif de la réunion.
• Ne pas faire autre chose en parallèle.

Phase d’idéation

L’idéation est la phase qui va permettre à toutes les personnes présentes de s’exprimer, sans être influencée. C’est en effet un moment de réflexion personnelle, en silence. C’est également le début d’une priorisation individuelle puisque le nombre de propositions par personne est limité : parmi mes idées, quelles sont pour moi les plus importantes ?

Les participants disposent premièrement de 7 minutes pour énumérer silencieusement les 5 bonnes pratiques qu’ils jugent être les plus importantes. Une idée par post-it, à décrire en quelques mots et en majuscules pour être lisible par tous. Une fois que tout le monde a compris et qu’il n’y a plus de question, on lance le minuteur. Si besoin, à la fin du temps, on pourra compléter de 3 minutes.

S’en suit une étape de partage et de mise en commun des idées. Tour à tour, les participants vont présenter leurs 5 post-it et les expliquer brièvement. Attention, ici le but est de partager et non de démarrer un débat. Les discussions viendront plus tard.

Pour faciliter et y voir plus clair pendant le partage, je rassemblais sous un même groupe les propositions identiques. J’ai aussi essayé de catégoriser les bonnes pratiques en deux : celles qui étaient plutôt Macro (faire du clean code, mettre en place telle architecture, …) et celles qui étaient Micro (15 lignes maximum pour une fonction).

Phase de priorisation

L’idéation générant de nombreuses propositions, il est essentiel de se concentrer sur quelques-unes d’entre elles pour avancer. Un moyen simple et rapide pour y parvenir est le dot-voting. Chaque participant dispose de plusieurs bâtons pour voter. En ajoutant un bâton sur un post-it, on le priorise davantage. Selon les variantes, on peut restreindre à mettre un seul de nos bâtons sur le même post-it.

Avec un groupe de 9 personnes, j’ai choisi de donner 3 bâtons chacun. À nouveau, cette étape se fera en silence afin de se concentrer et de choisir seul, et de ne pas lancer de débat maintenant. Le temps donné au groupe pour voter est de 5 minutes.

À l’issue des 5 minutes, on effectue une sélection de tout ce qui a plus de 1 vote. Un minimum de 2 votes donc, afin que la proposition soit partagée par au moins une autre personne (à adapter à la situation). On les regroupe ensuite plus bas, en les ordonnant par nombre de votes. Ce seront les sujets sur lesquels se concentrer pour les discussions.

Phase de discussions

L’idéation a généré de multiples propositions puis la priorisation a permis de sélectionner les sujets sur lesquels prendre du temps pour avancer. Il est maintenant temps d’en discuter plus en détail.

On commence donc les échanges en prenant le post-it qui a reçu le plus de votes. Lors des discussions, il est important de garder en tête l’objectif de l’atelier : faire émerger les premières bonnes pratiques. Plusieurs questions peuvent guider les discussions. Comment clarifier davantage ? Qui s’oppose ? Que faut-il pour être d’accord ? Que faut-il faire ensuite ? Comment rendre l’idée actionnable ?

Les discussions autour de chaque post-it sont minutées. La timebox permet d’aller vers l’essentiel et de ne pas monopoliser trop de temps sur un sujet. Au bout de 5 minutes, si l’idée est partagée par le groupe et est assez explicite, on peut la glisser dans une zone de résultats qui regroupe les bonnes pratiques à suivre. Puis on passe à la proposition suivante.

Sinon, lorsque les discussions ne sont pas terminées, le groupe peut effectuer un rapide vote pour décider de prendre 5 minutes supplémentaires. Un pouce vers le haut pour continuer, un pouce vers le bas pour passer au prochain sujet. Tous les participants votent en même temps. Lorsque la proposition est mise de côté, on peut prévoir une action pour avancer dessus en dehors de l’atelier.

Retour d’expérience 🔍

La durée de l’atelier a été de 1h15. Je prévoyais entre 1h et 1h30, cela me semble une bonne durée pour rester efficace, notamment à distance. Les retours des participants ont été très positifs et la moyenne du ROTI (Return On Time Invested) a été de 4,2.

Nous avons construit cette liste de bonnes pratiques ensemble. Elle n’est pas immense, ni complète. ll manque très certainement des choses. Mais ce n’était pas notre but. L’objectif était d’amorcer et de faire émerger de premières bonnes pratiques communes à mettre en place tout de suite, et c’est ce que nous avons fait. Chaque participant était satisfait du résultat final.

Nous étions également contents de notre efficacité et productivité. En suivant ce format, nous avons mis l’effort sur des sujets que l’on jugeait important. Nous avons évité des sujets à débat et nous avons réussi à trouver des plus petits incréments lorsque les propositions étaient trop grosses.

Quelques jours après cet atelier, de premières actions ont été réalisées. Un point d’échange au sujet de la mise en place de Design System en démontrant un PoC au reste de l’expertise, par exemple. Ou encore la création de la page wiki rassemblant les premières bonnes pratiques, et ayant pour vocation d’évoluer dans le temps. Une synergie est née au sein de l’expertise.

Une piste d’amélioration pour le format serait de supprimer la distinction micro/macro lors de l’idéation. Mettre les post-it dans ces catégories n’a pas apporté grand chose, ne pas l’avoir fait n’aurait rien changé. Il faudrait creuser son rôle ou simplement retirer cette idée.

Enfin, des éléments du 1–2–4-All pourrait être une variante intéressante de la phase de priorisation. Cela permettrait de faire travailler davantage l’intelligence collective. C’est une idée à tester.

Atelier à distance

Lorsque la contrainte d’effectuer cet atelier à distance est apparue, je me suis demandé à quel point on allait être moins productif et ce que l’on allait perdre. Avec le recul, effectuer un atelier à distance est tout à fait envisageable et peut être autant efficace. On peut même y trouver certains avantages.

La préparation de l’atelier en amont est importante. J’ai mis davantage d’efforts lorsque j’ai commencé à le prévoir à distance. Le fait d’avoir un cadre et de pouvoir guider avec une ligne directrice a beaucoup aidé. Avec une bonne dynamique, il est possible d’avoir tous les participants concentrés.

Le partage d’un support visuel, ainsi que la possibilité pour tous d’interagir avec, permet d’impliquer tout le monde et de les garder concerné. Le choix de l’outil a son importance, et je conseille de bien le tester en amont afin d’être à l’aise le jour J pour animer.

Être chacun à distance, en conférence audio (ou visio), nécessite de s’écouter. Plus que d’habitude. Il faut savoir laisser la parole aux autres et s’ouvrir. C’est une nécessité pour que les discussions soient constructives et ne soient pas chaotiques, mais cela apporte également des avantages. Par exemple, les silences plus nombreux offrent plus de réflexion. Cela ajoute une prise de recul pour moins de réactions à chaud. Un bénéfice bienvenu lorsqu’il s’agit de collaborer.

La difficulté fut de savoir si tout le monde avait compris ou avait terminé lorsque je le demandais car mes questions ne généraient pas de réponse. Je les ai donc changées en cours de route, en cherchant plutôt une réaction dans le cas contraire : “qui n’a pas terminé ?”.

A propos de draft.io

J’ai apprécié les fonctionnalités de draft.io pour animer cet atelier, notamment la possibilité de mixer de la présentation (du texte, des images, des traits…) avec de l’interaction (minuteur, post-it, vote).

Il est d’ailleurs possible de figer certains éléments, pour ne pas les éditer ou les déplacer par erreur. Ainsi, il est aisé de créer un tableau, un quadrant ou tout autre structure qui accueillerait des post-it. Ceux-ci sont assez complets. Ils ont plusieurs formats, couleurs, s’adaptent au texte, et surtout, ont un système de vote intégré.

Dernier exemple de fonctionnalité intéressante pour la collaboration, il est possible qu’une personne active un suivi de caméra : le draft de tous les autres participants se centrera sur son point de vue, puis suivra ses mouvements.

Vue d’ensemble du draft 🖼

Ayant fait l’atelier à distance, je vous partage un export image si vous souhaitez découvrir l’ensemble du support pour l’atelier. Libre à vous de l’utiliser ou de vous en inspirer.

Par les corbeaux d’Odin ! Tu découvriras comment scénariser ta rétrospective avec Kaamelott et comment contribuer à de nouveaux scénarios et univers avant la fin du soleil couchant, Arthur. ~ Un viking agile.

Lors de mon passage à Radio France, j’ai été SCRUM Master de l’équipe France Musique. Je variais occasionnellement les rétrospectives afin d’adapter le format aux situations et à la vie de l’équipe, et également pour leur faire découvrir de nouvelles choses en cassant la routine.

A l’issue d’une rétro, un des développeurs me lance “hey, t’aurais pas un format Kaamelott dans ton sac de master ?”, directement appuyé par un de ses collègues qui adoraient encore plus la saga. Malheureusement, non, je n’avais pas ça en stock.

Cependant, étant moi-même un fan invétéré de la série forgée par Alexandre Astier, cette phrase sonnait comme un challenge. Il fallait que je fasse quelque chose. Au nom du Graal !

Raconter une histoire 📖

N’ayant pas trouvé de rétrospective existante sur le thème de Kaamelott après une rapide recherche, je me suis donné pour objectif d’en créer une. Concevoir une rétro ok, mais sous quel format ?

Une première idée aurait été d’adapter une rétrospective existante, comme le speedboat, en collant du Kaamelott par-dessus. Probablement simple. Mais je voulais quelque chose pour les plonger dans l’univers. Tiens, plonger dans l’univers… Raconter une histoire ! Mais oui !

J’aime bien raconter des histoires, du coup j’ai tout de suite aimé cette idée. Quoi de mieux qu’une histoire offrant des personnages, des lieux, ou encore des actions pour maximiser l’immersion dans un univers ? C’est, en tout cas, simple et ça offre beaucoup de possibilités ; il n’y a qu’à laisser libre cours à son imagination.

Une histoire permet également d’avancer progressivement. On suit un fil directeur et plusieurs moments clés se présentent sur le chemin. La notion de chapitre est aussi intéressante, elle découpe l’intrigue en plusieurs parties.

Au final, on est guidé par le narrateur. Nous sommes plongés dans son univers, nous allons là où il souhaite nous emmener, et nous y allons à son rythme.

La rétrospective Kaamelott 🏰

C’est à partir de cette idéation que j’ai créé la rétrospective. J’ai d’abord déterminé les axes de réflexions que je voulais aborder durant ce rituel puis j’ai rédigé un scénario pour guider la rétrospective.

Comment ça marche ?

C’est très simple, il y a un script à suivre. Vous avez simplement besoin qu’une personne conte l’histoire. Probablement le facilitateur. Plus cette personne jouera le jeu et y mettra du sien, plus la rétrospective sera immersive.

La narration commence dès le début. L’équipe se plonge immédiatement dans l’univers avec une introduction. Le scénario progresse puis se dirige vers un premier axe de réflexion : les points positifs. Celui-ci est mis en scène et donne du temps d’introspection à l’équipe. En effet, la narration s’interrompt quelques minutes pour que chacun se concentre sur ce qu’il souhaiterait dire.

L’histoire reprend ensuite, relatant de nouvelles aventures et s’arrêtant de la même manière au prochain axe, et ainsi de suite jusqu’à se terminer par la recherche d’actions.

C’est la particularité de ce format : l’équipe se concentre sur un axe de réflexion à la fois en les découvrant au fur et à mesure de la progression du scénario. Cette rétrospective aborde donc individuellement les points positifs, les points d’améliorations, les idées en tout genre, et enfin les questions, craintes et doutes.

Le script contient tous les détails. Le texte à conter, les temps de pause, des indications pour faciliter, ainsi que de possibles variantes.

https://github.com/chapuyj/scripted-retrospective/blob/master/scripts/kaamelott_un-sejour-a-kaamelott_20191026.md

Des essais et des feedbacks

J’ai pu tester ce format à trois reprises, dont une récemment pour la rédaction de cet article. Avec à chaque fois un public mixte (fans de Kaamelott et incultes), les retours ont été très positifs.

Les principaux feedbacks mentionnaient l’immersion. Les personnes présentes ont beaucoup apprécié se plonger dans un univers et se laisser accompagner par une histoire. Pour certaines, cela apportait également de la gamification. C’était quelque chose d’original. J’ai aussi pu observer que des personnes réservées étaient plus à l’aise.

Plusieurs autres retours ont mis en valeur la réflexion étape par étape. Il était intéressant et pratique de se concentrer sur une catégorie de la rétro à la fois.

L’axe d’amélioration qu’on m’a partagé était de travailler la fin de l’histoire pour que ce soit moins brut avant le passage aux actions. J’ai alors complété le scénario il y a peu, ce sera à tester de nouveau.

Une rétrospective scénarisée 📜

Si l’idée de départ était de créer une rétrospective Kaamelott, un format plus général est également né. Kaamelott est un univers, c’est un thème pour la rétrospective. Cela a apporté de la couleur, mais la forme, elle, n’en dépend pas.

Au travers d’une histoire, plusieurs caractéristiques et libertés définissent le format de cette rétrospective. La première et principale caractéristique est qu’une histoire est narrée. Ça semble évident, mais c’est un point important. La rétrospective repose là-dessus.

Cela implique un scénario complet à préparer. En découle aussi une liberté totale sur ce que l’on veut explorer, et comment. On peut s’adapter et déterminer sur quels points se concentrer pour cette rétrospective : faire émerger des axes d’améliorations, des points bloquants, des craintes, ou bien des problèmes de communications. En ce qui concerne le comment, l’imagination sera la seule limite. Univers, personnages, dialogues, actions, … Les possibilités sont infinies.

Le découpage en plusieurs étapes d’introspection forme la seconde grande caractéristique du format. Le scénario pose un contexte puis nous guide vers chacun des axes de la rétrospective, progressivement. À chaque étape, l’histoire s’arrête afin de donner du temps à l’équipe pour générer des sujets sur cet axe précis. Puis la narration reprend et continue jusqu’à avoir parcouru toutes les étapes.

On découvre ainsi les étapes au fur et à mesure, et on se concentre sur une chose à la fois. Une des possibilités offerte est de pouvoir choisir la durée de réflexion de chaque étape, indépendamment. Une autre liberté est d’échanger tout de suite après le temps de réflexion plutôt que d’attendre la fin. La dernière étape deviendrait seulement de la recherche d’actions. Libre à vous de choisir et d’adapter selon vos envies.

J’appelle donc ce concept une rétrospective scénarisée. Une histoire nous plonge dans une suite d’évènements et d’introspections, et se termine par la recherche d’actions pour s’approcher du Graal.

Contribuez avec votre scénario ✍

Les fans de Kaamelott ont adoré retrouver l’environnement de leur série fétiche. Cela peut être un bon point de retrouver quelque chose de connu et apprécié, alors pourquoi ne pas étendre ce format à d’autres univers ? C’est dans cette optique que j’ai mis à disposition mon idée sur GitHub : permettre à n’importe qui de collaborer et d’ajouter de nouveaux scénarios. Ouvrez une Pull Request sur GitHub ou contactez moi via Twitter.

https://github.com/chapuyj/scripted-retrospective

Que ce soit pour un univers déjà présent ou un n’ayant pas encore de scénario, une simple variante ou l’exploration d’autres axes, soyez libre. Vous pouvez vous inspirer de mon premier scénario sur Kaamelott pour vous lancer, ou de ma description d’une rétrospective scénarisée.

Vous pouvez même essayer quelque chose de différent ! Qui sait, une merveilleuse idée pourrait voir le jour. Ce fut d’ailleurs le cas puisque cette rétrospective scénarisée m’a ensuite inspiré un autre format. Une rétrospective avec un jeu de cartes Kaamelott spécialement créé pour. Mais je n’en dirais pas plus, il faudra attendre un prochain article.

Fin du livre 👋

Merci pour votre lecture. Qu’en pensez-vous ? N’hésitez pas à me faire part de vos avis, questions, ou remarques. Je suis preneur de tout feedback. Et si l’envie vous prend de rédiger votre propre scénario, je serai ravi de le lire et l’ajouter sur GitHub.

À benext, les développeurs sont en projet dans les locaux de différents clients, mais ce n’est pas pour autant qu’on ne se voit pas. Nous nous retrouvons au siège de benext, le vaisseau (en référence à la passion pour Star Wars qui anime le fondateur), dès que nous pouvons. Meetups internes, DOJOs, coaching, beCom, soirées, sur des sujets techniques, produit, agile, de développement personnel ou encore pour le fun, toutes les raisons sont bonnes pour échanger et apprendre des autres.

La recherche d’excellence est d’ailleurs une valeur très forte à benext. Par excellence, nous n’entendons pas être les meilleurs. La nuance se situe dans l’amélioration, l’amélioration continue. Chercher à progresser et à faire progresser les autres. À travers nos communautés et nos cercles (notre système d’organisation est proche de l’holacratie), nous avons la possibilité d’agir en ce sens.

J’ai donc proposé de libérer les développeurs iOS de leur projet le temps d’une demie-journée. Chacun étant sur des projets différents, l’objectif principal était de nous réunir pour échanger, apprendre et travailler ensemble sur diverses problématiques. Le mélange de ces multiples contextes, compétences, connaissances, besoins, de toute cette hétérogénéité, ne pouvait qu’être enrichissante pour tous. Et ce fut le cas.

Voici le récit d’une après-midi d’échanges entre développeurs.

Les préparatifs

Remontons un peu le temps. Environ un mois avant d’entamer cette prometteuse après-midi, j’ai commencé par la préparer afin d’en retirer un maximum de valeur. J’avais deux axes à travailler : le contenu et le format.

Appel à idées 🗳

Afin de s’assurer un minimum de matière pour échanger, j’ai demandé à mes collègues de réfléchir aux différents sujets qu’ils souhaiteraient aborder. Cela permet aussi de déterminer en amont s’il y a un intérêt à préparer un atelier, une formation, un support à partager, etc.

J’ai lancé l’appel à idées trois semaines avant notre rencontre, suivi de plusieurs relances. Pas trop de complexité pour cette étape, j’ai partagé un Google Sheet pour recueillir les propositions, et j’ai utilisé Slack pour communiquer. Pour différencier les types de sujet, j’ai proposé quatre catégories :

• Client : vous avez une problématique dans votre projet, et vous avez besoin d’aide, d’avis, de conseils, etc.
• Partage: vous avez envie de partager quelque chose que vous avez découvert ou que vous maîtrisez, et qui pourrait intéresser les autres.
• Demande : vous souhaitez en apprendre plus sur un sujet, comprendre un pattern, ou approfondir une technique. - Peut-être qu’une autre personne peut vous transmettre sa connaissance sur ce sujet.
• Action : vous voulez effectuer une action pour votre cercle, votre communauté, ou pour vous.

Aucune limite dans le nombre de propositions. Plus il y a de matière, plus on peut avoir du choix et être flexible le jour même. D’ailleurs, le pré-remplissage de ce document ne ferme pas la porte à l’improvisation et aux demandes de dernière minute. Le programme est établi au début de l’après-midi, avec tout le monde.

La création du format 🖼

J’avais le pourquoi, apprendre et échanger ensemble, et le quoi était en train de se remplir dans le Google Sheet. Il me restait donc à trouver le comment.

J’aime beaucoup la culture agile ainsi que les méthodes et ateliers qui en découlent, alors j’ai commencé par piocher dans mes connaissances. Cadrer, faciliter, timer, avoir des créneaux horaires, … De premières idées me viennent. J’ai également la chance d’être à benext, une entreprise qui baigne dans l’agilité. Je me suis inspiré de ce que l’on faisait, et j’ai discuté avec des personnes organisant des événements ayant des points communs.

Bastien, un Scrum Master, a été la première personne avec qui j’ai échangé. Bastien anime régulièrement le We Open Space. Le principe ? Réunir des gens de tout horizon une journée complète afin de partager autour de multiples sujets. C’est ouvert à tous, et on y retrouve des thématiques très variées. L’organisation est inspirée de l’Open Space Technology : on y retrouve un Forum Ouvert avec beaucoup de bienveillance, d’échanges, d’auto-organisation, etc. Un échange très enrichissant avec lequel j’ai pu approfondir certaines connaissances et découvrir de nouveaux concepts et pratiques.

Peu de temps après, j’ai retrouvé Camille, une Product Owner. C’est l’une des organisatrices du GrowTogether, une journée d’intervision entre PO où sont en plus conviés les clients. Une partie de ses enjeux pouvaient s’apparenter aux miens. Grâce à son retour d’expérience, j’ai pu mieux cerner leurs problématiques et leur organisation.

Avec toutes les billes que j’avais dans mon sac, j’ai imaginé une première version du système d’organisation. J’en étais très content, mais des questions persistaient. C’est pourquoi j’ai fait appel à Nils, un coach agile. Je voulais avoir un avis et également me faire challenger en plus de répondre à mes questions. Quelques conseils plus tard, un premier format était né. Il n’y avait plus qu’à attendre le jour J et j’étais impatient.

Le déroulement de l’après-midi

Petit saut dans le temps, le grand jour est enfin là. Arrivée de mes collègues à 13h40. Le temps de s’installer dans la salle et de terminer les discussions, le début des hostilités est donné à 14h00. D’ailleurs, en parlant de terminer les discussions…

Un icebreaker pour bien démarrer ⛄️

Avant d’entrer dans le vif du sujet, j’ai proposé un rapide icebreaker au groupe. Même si nous nous connaissions déjà tous bien, il y avait une seconde raison pour faire cet exercice : capturer l’attention des participants. Au début d’un atelier ou après une pause, le groupe peut être dissipé et avoir de multiples discussions annexes (boulot, dernières nouvelles, blagues, …). C’est là qu’entre en jeu l’icebreaker.

D’une manière originale et ludique, on obtient l’attention de tout le monde et on recentre les discussions sur l’atelier. En bonus, on apprend de nouvelles choses sur nos collègues. Il existe tout un tas d’icebreaker, de différentes formes, et même le plus simple d’entre eux fonctionne. En voici deux rapides à mettre en place :

• Posez la question “Aujourd’hui, quel animal êtes-vous et pourquoi ?”. Un exemple de réponse pourrait être “je suis un chat aujourd’hui, car je me sens très joueur et j’ai beaucoup d’énergie, j’ai envie de sauter partout”.
• Demandez à chaque participant de trouver trois affirmations sur eux, une vraie et deux fausses. “Je suis allé sur un volcan / J’ai sauté en parachute / Je sais parler 4 langues”. Tour à tour, chaque personne énoncera ses propositions, et le reste du groupe devra deviner laquelle est réelle. Indiquez aux personnes de donner des informations peu banales pour rendre l’exercice plus facile et plus amusant.

Une fois toute l’attention acquise, j’en ai profité pour rappeler certaines règles et principes.

Un cadre de bienveillance ⭐️

Mettre en place un environnement bienveillant est important pour favoriser la collaboration. Quelques règles simples suffisent :

• Une discussion à la fois. Laissons parler tout le monde et écoutons nous.
• Les personnes présentes sont les bonnes personnes.
• Ce qui arrive est la meilleure chose qui pouvait arriver.
• Ça commence quand ça commence, et ça termine quand ça termine.

Les bonnes personnes étaient là, le cadre était posé, il ne restait plus qu’une étape avant de commencer : la conception de notre programme.

La place du marché 🛍

Vous vous souvenez de l’appel à sujets et du document à remplir ? Le moment était venu de l’utiliser et de planifier ensemble le reste de l’après-midi.

Première étape, retranscrire les propositions sur des post-it puis les rassembler au tableau pour que ce soit visuel. Un sujet par post-it, avec le titre et la catégorie. C’est aussi le moment où l’on peut proposer des sujets de dernière minute.

En parallèle, j’ai dessiné une timeline. L’axe des X représente le temps, par tranche de 30 minutes, et l’axe des Y correspond à des salles. On retrouve donc un quadrillage où chaque case associe un créneau horaire et une salle. J’y ai aussi indiqué un créneau de pause, pour se libérer l’esprit et se recharger.

Le fait d’avoir plusieurs salles permet de se diviser en plusieurs groupes et de traiter plusieurs sujets en parallèle. Nous avons cependant convenu de minimiser l’utilisation de plusieurs salles, un des enjeux de cette après-midi était de se retrouver tous ensemble.

Quant aux créneaux de 30 minutes, le but est de timeboxer chaque sujet afin de rester efficace et de ne pas s’étendre sur un point sans qu’il n’y ait un intérêt. Cependant, une extension de temps est possible : à la fin des 30 minutes, le groupe peut décider de racheter du temps, 5 minutes supplémentaires, en votant.

Le rachat est possible autant de fois que nécessaire, tant que le groupe est d’accord. Le protocole de décision est d’ailleurs décidé en équipe, pendant la place du marché, afin de déterminer le nombre de voix positive requise pour racheter du temps. Ainsi, on ajoute une valeur au temps et à la possibilité de continuer.

Une fois que tout était prêt, il ne restait plus qu’à construire le programme ensemble. Nous avons priorisé rapidement à l’aide du dot voting puis nous avons remplis la timeline.

Les OpenSpaces 🏡

Le programme fin prêt, nous pouvions commencer. Pour garder une trace des sujets traités, j’ai créé un document partagé que tout le monde pouvait remplir. Pour chaque sujet, nous notions un contexte ainsi que les décisions et actions prises.

Nous avons choisi de démarrer par des créneaux de production personnelle, où nous avons principalement préparé des sujets de talks. Nous avons décidé que ce serait le seul créneau où nous divisions le groupe afin de pouvoir profiter au maximum d’être tous ensemble.

Les points que nous avons abordés étaient variés : réflexion et actions autour de la création de l’entretien technique iOS, échanges autour d’une problématique client sur les Tests UI et l’injection de dépendances, des discussions autour de la création d’un meetup et de sujets de talks, du feedback sur un article et un Call For Papers, ou encore des idées pour se challenger, se motiver, et rayonner avec sa communauté.

Nous avons acheté du temps supplémentaire pour un seul sujet. Lors des prolongations, nous nous sommes focalisé à trouver des actions et avons décider de nous revoir pour un point précis afin de clore le sujet et avancer. À l’inverse, deux sujets se sont terminés quelques minutes en avance. Nous en avons profité pour enchainer sur les points suivants.

Un goûter healthy nous attendait lors de notre pause. Nous avons pu nous ressourcer 20 minutes avant de reprendre les hostilités. Nous avons d’ailleurs modifié la suite du programme à notre retour.

Au final, nous avons pu traiter 6 sujets, en plus des 3 effectués en parallèle au démarrage. Nous avons tenté de définir au moins une action à l’issue de chaque point. L’enchaînement des créneaux était intense, mais nous étions tous content de notre travail et nous en sommes ressortis avec du concret.

Rétrospective 📣

Pour terminer cette demie-journée, nous avons fait une rétrospective pour obtenir du feedback. Je l’ai axée sur comment faire mieux pour la prochaine fois avec ces cinq points :

• Les nouveautés à avoir
• Les points à améliorer
• Ce que l’on garde
• Ce que l’on enlève
• Des remerciements

Globalement, cette rencontre a été très appréciée. Le groupe s’est senti efficace et a apprécié cette organisation avec de petits créneaux et un fort timeboxing. Les sujets ont intéressé tout le monde et beaucoup d’actions ont été prises.

Des points d’amélioration ont aussi été proposés. Nous avons parfois eu deux discussions simultanées, ce qui a fait perdre de l’information. Il est important de bien écouter la personne qui parle et de ne pas avoir plusieurs conversations. Notre groupe se connaissant déjà très bien, nous nous sommes aussi demandé si l’icebreaker pouvait avoir une autre forme.

Enfin, les créneaux de production individuelle nous semblaient à éviter, ou au moins à limiter. Ce n’est en effet pas l’objectif principal de ce type de rencontre, et la production n’apporte pas directement de la valeur pour le groupe. Proposer plusieurs salles est à préférer si les sous-groupes formés sont assez grand pour avoir des échanges constructifs.

ROTI 🖐

Avant de partir, nous avons fait un ROTI (Return on Time Invested). C’est un vote très rapide à faire : en même temps, chaque participant indique à main levée une note entre 1 et 5 pour évaluer le temps investi. Une personne votant 5 indique que ça valait tout le temps investi, et même plus, alors qu’un 1 indique que sa présence était inutile. Il est intéressant de demander “pourquoi” et ce qu’il aurait fallu pour mettre un point de plus.

Conclusion

J’ai beaucoup aimé organiser cette après-midi. Dès la préparation, j’ai pu apprendre de mes échanges et de la création du format. Je remercie d’ailleurs à nouveau les personnes qui m’ont aidé. J’ai également joué le rôle de facilitateur pendant la demie-journée, un rôle que j’apprécie et sur lequel j’ai pu continuer à monter en compétences.

À l’issue de la journée, nous étions tous satisfait du résultat. Nous nous sommes enrichis de diverses connaissances, nous avons échangé, nous nous sommes aidé, nous avons proposé des solutions à des problèmes, et nous avons décidé d’actions à prendre. De multiples actions concrètes sont ressortis de cette rencontre.

Avec le timeboxing, les Open Spaces étaient productifs et intenses, sans que le temps soit un poids. Nous n’avons pas eu l’impression de courir contre la montre, et nous étions motivé à être efficace. Pour un petit groupe, il est intéressant de privilégier une seule salle de travail afin de maximiser la collaboration et l’intelligence collective.

J’aimerais maintenant pouvoir renouveler cette expérience avec des conditions différentes. Par exemple, en variant la durée (sur une journée complète), le domaine technique (mélange de développeurs de plusieurs horizons), ou encore en ouvrant à des externes. Je me demande comment faire évoluer le format.

Principalement, que faudrait-il adapter pour réunir des développeurs travaillant avec des technos et langages différents ? Cette fois-ci, nous étions tous développeurs iOS. Est-ce qu’un plus grand nombre avec plusieurs salles par créneau horaire suffirait ? Ou peut-être faudrait-il davantage axer sur des sujets de programmations plus générales ? Voire ajouter des problèmes d’organisation ?

Pour étendre le format sur toute une journée, le système d’OpenSpaces devrait toujours fonctionner. Éventuellement, on doit pouvoir remplacer quelques créneaux par des ateliers. Ces ateliers auraient par exemple la forme de DOJOs ou de talks préparés en amont.

Si l’occasion se présente, ce sera le moment de tester en variant un peu ce format. Le récit ne demande qu’à continuer.