Je pense par exemple au flux que la story doit traverser, aux process, aux pratiques tech et produit, à la façon de communiquer et de collaborer, etc. On n’a peut-être pas besoin de faire constamment du discovery, des cadrages, des Event Storming. Peut-être que parfois les experts ont besoin de travailler tous ensemble alors que d’autres moments non.

C’est une idée qui m’est venu spontanément en route vers Reims pour visiter la cave aux coquillages - il n’y a aucun rapport, mais mon cerveau en avait décidé ainsi. J’ai divagué une partie du trajet dessus, j’aimais bien le cheminement que je faisais dans ma tête et les possibilités qui s’ouvraient. J’ai envie de partager ces réflexions pour continuer à les faire mûrir. Merci Nils pour nos premiers échanges ;)

Note : je parle de « user story » tout le long de l’article, par simplicité pour l’écriture, mais l’idée peut s’appliquer à d’autres unités ou éléments de travail comme une epic par exemple.

Un mot sur Cynefin

Derrière les 4 lieux que je citais (simple, compliqué, complexe, chaos) se cache Cynefin. C’est un modèle qui permet d’adapter la manière d’aborder un problème selon sa complexité pour mieux y répondre. Pour chacun des lieux, le modèle propose différentes manières de réagir, de décider, de communiquer. En se posant quelques questions « Est-ce qu’il y a une réponse ? Est-ce qu’on va réussir ? », en regardant où sont les inconnues, on peut situer la problématique dans un de ces lieux.

Je me souviens de la première fois que j’ai vu Cynefin en action. C’était lors d’un point sur la stratégie de notre communauté tech à BENEXT, il y a plusieurs années. Nils lança soudainement : « OK, on est en train de se dire qu’on ne sait pas si on y arrivera. Je pense qu’on est dans le domaine du complexe. Donc ça veut dire qu’il faut qu’on teste. On va arrêter de réfléchir et on va essayer des choses. ». J’ai trouvé ça génial.

Adapter sa manière de traiter les stories

Maintenant, regardons ce que ça pourrait donner avec la fabrication de logiciels, au moment où l’équipe se retrouve devant des user stories de différentes complexités - ce que veulent dire ces complexités, les comportements que l’équipe pourrait adopter, les pratiques.

Simple

Est-ce qu’il y a une réponse à ce problème ? Oui. Est-ce que nous la connaissons ? Oui. Dans le simple, on n’a pas d’inconnue. On sait comment on va faire cette story, techniquement et fonctionnellement. Faisons.

J’imagine une story qui a peu de règles métier, peu de particularités de design. Donnez-moi une story avec seulement un titre et une phrase en description, ça me suffit. Pas besoin d’un long cahier des charges, peut-être pas besoin de créer des maquettes non plus ; je privilégierai les discussions et l’instant présent.

Il y a principalement une collaboration entre le demandeur et le faiseur. PO et dev, par exemple. On communique beaucoup ensemble. Peut-être que le PO pourrait s’asseoir à côté de moi pour développer en direct ce morceau. On n’a pas besoin d’impliquer tous les autres devs, ou tout le produit, ou tous les designers.

Le “comment”, on sait faire. Il n’est pas nécessaire de réunir tous les experts (techniques, design, …) pour faire de la conception en amont, ou de multiples relectures et validations en aval. Je pourrais partir seul sur ce sujet, et il pourrait y avoir plusieurs sujets simples qui avancent en parallèle dans l’équipe sans problème.

Ça ne nécessite donc que peu de process et de pratiques en place. On est sur du léger. Après tout, c’est simple alors faisons simple aussi.

Compliqué

Est-ce qu’il y a une réponse ? Oui. Est-ce que nous la connaissons ? Non. Cette fois, il y aura besoin d’analyser et de chercher des réponses pour réaliser cette user story. On a des inconnues mais on trouvera.

Là, peut-être que les règles sont compliquées, nombreuses. Peut-être que j’ai besoin d’un jeu de données plus fourni, d’un environnement dédié, de maquettes. Peut-être que l’on peut découper ; sûrement même ! On va regarder. L’Example Mapping pourrait être une bonne pratique à intégrer pour à la fois bien comprendre les règles et découper.

Si la technique est compliquée, j’aurai davantage envie de travailler en groupe. Du pair-programming voire mob-programming. Peut-être qu’on fera une phase de conception technique ensemble, qu’on dessinera sur un tableau, qu’on déterminera des contrats d’interface.

Toute l’équipe se parle, on a besoin de beaucoup d’échanges et il faut que le cadre, l’organisation le permette. Je pense au passage à l’Event Storming, pour réunir toutes les bonnes personnes, pour s’aligner, pour comprendre notre système.

On va peut-être trouver plusieurs solutions. Et si on faisait de l’A/B testing ou du Feature Flagging ? Ça permettrait au passage d’éviter de se paralyser dans l’analyse - c’est le risque quand on est dans le compliqué, il faut en sortir à un moment et répondre au problème, livrer de la valeur. On pourrait aussi se timeboxer.

Complexe

Est-ce que c’est faisable ? Est-ce qu’on va réussir ? Probablement. Dans le complexe, l’incertitude est présente. Il y a des inconnues et on ne sait pas si on trouvera. C’est différent du compliqué où l’on sait qu’il y a une réponse - là, on a besoin d’explorer et de tester.

Peut-être qu’il y a trop de choses qui s’entremêlent, fonctionnellement ou techniquement, chez nous et/ou avec une autre équipe, un partenaire externe. On ne peut pas prédire les choses. On ne peut pas analyser ou découper non plus. Chercher à estimer le temps que prendrait cette story serait un non-sens. On est dans le complexe ! Les incertitudes et les inconnues nous entourent. Ici, il n’y a pas de liens de cause à effet clairs.

On veut explorer. Je pense à une phase de product discovery, des ateliers avec des utilisateurs, des user journeys. À l’Event Storming pour découvrir des domaines métiers.

On veut tester. Je pense à un Design Sprint. Je pense à toutes les techniques de développement pour tester en production également - A/B Testing pour essayer des variantes, Canary Release pour avoir un petit groupe d’early adopters, Feature Flag pour activer/désactiver facilement et rapidement. Une équipe capable de faire du déploiement en continu (CD) sera plus à l’aise pour lancer des expérimentations et s’adapter aux changements.

On va découvrir une partie des éléments seulement en faisant. On ne peut pas tout prévoir, il y a des choses qui n’apparaîtront que lorsque l’on fabriquera, qu’on aura les mains dedans. On peut se poser la question de ce que l’on peut essayer de faire maintenant, pour se mettre en marche. On a des dépendances externes et des inconnues ? On ne pourra pas tout planifier parfaitement, découvrons en chemin. C’est quoi les petites choses que l’on peut démarrer maintenant ?

Il faut de l’émergence. On va multiplier les expérimentations et on va se détacher du donneur d’ordre (on veut faire émerger !). Peut-être qu’on pète l’équipe, peut-être qu’on fait trois trios par exemple. On est lundi matin, mercredi on regarde ce que chaque trio a fait, ce qu’on a appris, ce qu’on teste ou met en prod.

Chaos

Un événement critique survient. Il surprend l’équipe, il déstabilise. Il était imprévisible. On est dans l’inconnu et on a peu de temps pour répondre, on a besoin d’agir maintenant.

Ce pourrait être le crash des applications, le serveur qui tombe, une fuite de données, une intrusion. Ça devient la priorité et on ne veut pas perdre de temps. On ne part pas en exploration ou en analyse.

D’abord, on règle le problème. On cherche une réponse rapide, pas parfaite. Quelques exemples d’options : on désactive la fonctionnalité grâce aux Feature Flags que l’on a mis en place. On redéploie la dernière release stable, on rollback. On corrige et on déploie un patch.

Après, une fois que le problème est réglé, on peut améliorer. Selon l’action que l’on a prise. Le correctif nécessite peut-être du refactoring, il nous faut peut-être une solution moins bricolée. Ou il faut réparer la release / la fonctionnalité, parce qu’on a juste rollback / désactivé via le feature flag.

On peut également analyser. Je pense à une rétrospective, un post-mortem. Qu’est-ce qu’on a appris ? Quelles pratiques sont apparues ? Qu’est-ce qu’il nous manquait ? Comment s’améliore-t-on pour la prochaine fois ?

On est plutôt sur un canal directif à l’apparition du problème. La personne qui fait le plus sens va donner la direction, l’action. « On fait ça maintenant et on fonce ». Mais on ne reste pas éternellement dans le command & control - le chaos se termine, on y sort.

Pour se préparer au chaos, on peut ajouter des pratiques pour réagir rapidement (pouvoir déployer une précédente release, désactiver les nouvelles fonctionnalités à distance, …) et pour mieux voir venir (monitoring, alerting, …). Et on peut aussi se plonger soi-même dans le chaos.

Je fais référence au Chaos Engineering. On provoque un chaos contrôlé pour s’immuniser (une notion dans Cynefin d’ailleurs !). L’équipe va apprendre à réagir en étant dans ce chaos et des pratiques émergeront pour mieux y faire face les prochaines fois. Un exemple connu est Netflix qui a testé sa résilience en faisant tomber volontairement ses serveurs. Le Chaos Monkey est né.

Pour autant, il reste difficile de prévoir le chaos. Il peut avoir plusieurs formes, il peut venir de partout. Je peux tester la résilience de mon infrastructure face aux serveurs de streaming qui tombent, mais, et si c’était les bases de données qui lâchaient ? Ou si le chaos était la fuite des utilisateurs, comment s’immuniser ? Quand est-ce que ça va arriver ? On ne sait pas.

Réflexions générales

Ce que j’aime beaucoup, c’est que ça aide l’équipe à réfléchir à comment elle va traiter les choses. Elle prend du recul et se pose des questions. Ça la pousse à s’adapter et à adapter ses processus - aucune raison de suivre toujours le même chemin, de sortir le bazooka pour tuer une mouche ou l’inverse d’aller en tong à la guerre.

Je parlais de user stories, mais on pourrait aussi bien faire l’exercice avec une granularité plus grande, comme une epic. On s’enlèverait des douleurs encore plus tôt. On pourrait voir qu’on a besoin d’explorer ce gros morceau par exemple, donc ne perdons pas de temps à spécifier maintenant. Ou quelque chose de plus vague comme une idée. Ah, c’est du simple, fonçons et testons en prod !

J’ai en tête des situations antérieures où l’équipe apportait une réponse inadaptée.

• Faire du compliqué et du complexe sur des sujets qui relevaient du simple. Ce qui donnait un mois de préparation (avec une longue discovery et beaucoup d’analyse, de prévision, de synchro) pour au final une après-midi de développement. Des frustrations sont nées de ce décalage entre le temps en amont et le temps utile à fabriquer.
• Faire du compliqué sur un sujet complexe. Malgré beaucoup d’analyses et de réunions techniques, il y a eu surprise sur surprise (ou découverte sur découverte ;)) à mesure que l’équipe avançait. De nouveaux imprévus chaque semaine qui remettaient en cause les prévisions. L’estimation de temps a explosé, le découpage ne convenait pas puisque c’était trop entremêlé, les spécifications tech changeaient. Beaucoup de douleurs à cause de choses virtuellement figées par l’équipe alors que dans le complexe, on découvre pendant qu’on fait. On ne peut pas être parfait et tout prévoir.

Je me dis que ça peut aider des équipes à essayer d’autres choses.

• Une équipe où tout le monde travaille toujours dans son coin pourrait repérer des sujets où il serait intéressant de se grouper, de faire du pair, de dessiner, de montrer, de partager, etc.
• Une équipe qui a un long flux de conception, beaucoup de travail de préparation et d’analyse, pourrait repérer progressivement des sujets simples pour alléger ses processus.
• Une équipe qui passe beaucoup d’énergie à estimer, seulement pour avoir le bon chiffre, pourrait se ramener à des questions plus utiles - est-ce qu’on peut découper ? Comment ? Faut-il explorer ?

J’aime bien toutes ces questions que le modèle peut ouvrir, les discussions et les changements qui peuvent en découler. L’étiquette au final, on s’en fout. C’est ce qu’on fera qui sera intéressant.

Je suis très preneur d’avoir des retours si vous l’essayez ou le challengez, pour savoir comment vous vous l’approprierez, ce que vous adapteriez, ce que ça provoque dans l’équipe, etc.

Je remercie à nouveau Nils pour nos discussions et j’en profite pour recommander son article et son meetup à ceux qui voudraient creuser le modèle Cynefin.

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.

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.