Pour poser un peu de contexte, nous sommes une vingtaine dans l’équipe, composés de multiples profils (tech, produit, terrain, design, …). La plupart sont situés en Île-de-France et les autres répartis dans différentes régions du pays. Il y a une seule règle autour du télétravail : on veut se retrouver tous ensemble physiquement les derniers jeudis du mois. Le reste du temps, chacun est libre de s’organiser comme bon lui semble - et c’est majoritairement à distance.

Ce qui m’a valu des questions de la famille, d’amis, d’autres collègues. « Pas trop dur d’être souvent en télétravail ? Tu te sens comment ? » Et même des affirmations « ah moi je pourrais pas ». Alors j’explique certains aspects que j’aime bien - flexibilité, auto-orga, temps libéré, etc. Des choses qu’on entend déjà bien assez avec les fervents défenseurs du télétravail sur LinkedIn.

J’explique qu’aussi, je me sens bien avec le télétravail dans cette équipe (j’insiste sur ce point) parce que j’ai l’impression d’avoir mes collègues à côté de moi. Tout le long de la journée, j’ai beaucoup d’échanges, du spontané, de l’informel, du lien. Du sérieux et des conneries. Je ne suis pas seul au final. Et là, je vois que je mets le doigt sur quelque chose. « Ah ouais, c’est pas mal », « Faut qu’on essaie ça chez nous ».

Je pense qu’un des ingrédients principal de notre télé-mayonnaise est notre utilisation de Discord.

Rester connecté vocalement

Je vulgarise pour ceux qui ne connaissent pas. Discord est une application qui permet à plusieurs personnes de discuter avec du texte et avec de l’audio/vidéo grâce à un système de canaux. Ce qui est particulièrement intéressant ici, ce sont les canaux vocaux.

Un canal vocal est toujours ouvert. On voit les personnes qui y sont connectées actuellement, et on peut les rejoindre (et partir) à tout moment. Par exemple, je vois que Alice et Bob sont sur le canal Kaamelott. Ça tombe bien, j’ai besoin de leurs avis. Je vais m’y connecter brièvement pour échanger avec eux sur ma problématique.

C’est différent des outils classiques comme Google Meet, Microsoft Teams ou Slack. Je n’ai pas besoin d’appeler une personne, ni de planifier une réunion sur un calendrier, ni de demander la disponibilité de quelqu’un. Je rejoins un espace de discussion et hop, je suis avec ces personnes. Je peux immédiatement parler et ils m’entendent. Ou l’inverse. J’étais seul et hop, quelqu’un me rejoint.

C’est très pratique. Et c’est devenu très puissant quand on a commencé à l’utiliser pleinement. Je m’explique. Au début, on l’utilisait pour quelques rituels et on s’envoyait des messages pour se dire « hey tu viens sur Discord 5 min stp ? ». Puis un jour, on a glissé sur un autre mode de fonctionnement.

Avec mes deux collègues devs mobile par exemple, on s’est mis à se connecter sur notre canal vocal « ici c’est le mobile » les matins et on y restait toute la journée*. Même lorsque l’on n’avait pas besoin de se parler ou de travailler ensemble.

Pourquoi ? Pour la spontanéité. À tout moment, je peux activer mon micro et parler avec mes collègues - ils sont déjà là, ils m’entendent et peuvent répondre.

C’est génial pour collaborer. On peut s’entraider, poser une question, réfléchir à voix haute et avoir d’autres avis, déclencher un pair programming à la volée. Ça laisse également plus de place pour de l’informel. On peut dériver d’un sujet, raconter soudainement une anecdote ou le film vu la veille.

Il n’y a pas de friction. On parle, tout simplement. C’est con mais terriblement efficace.

*Connecté toute la journée : bien entendu, on se déconnecte d’un canal si on a autre chose à faire, besoin de focus, ou tout simplement si on a envie de couper. Aucune obligation.

Encore plus accueillant

La semaine dernière, j’ai fais une expérimentation pour aller un cran plus loin. On était content avec ce système dans l’équipe, mais il y avait majoritairement des développeurs connectés sur les canaux. On avait également trop de canaux (20 !) et plutôt silotés - « devs back 1 », « devs back 2 », « mobile », « recette », etc. En discutant avec d’autres profils dans l’équipe, je sentais qu’il y avait un intérêt et qu’on pouvait les embarquer.

Jeudi matin, j’ai tout supprimé puis j’ai créé une poignée de canaux. Différemment.

• Un groupe « Ouvert » avec 5 canaux. N’importe qui peut rejoindre n’importe quand. C’est ouvert. J’y vais pour travailler avec les personnes présentes, pour discuter, juste écouter en fond. Ou j’y vais seul pour que d’autres me rejoignent s’ils en ont envie à un moment.
• Un groupe « Privé » avec 2 canaux. Ici, je suis plutôt focus, je préfère ne pas être dérangé, sauf sujet important.
• Des univers et des lieux comme nom de canal. Quelque chose de générique pour ne pas se fermer sur un métier ou une action. « Kaamelott », « Pixar », « Montagne ».

L’idée que j’avais derrière la tête ce matin-là, qui me guidait, c’était de créer un environnement permettentant aux gens de se croiser plus naturellement. En se groupant, et en se mélangeant. De manière prévue, et imprévue.

J’avais envie qu’une personne soit davantage tentée de rejoindre un canal avec d’autres personnes. Le groupe ouvert va dans ce sens, et les noms des canaux ne sont pas excluants. La réduction du nombre de canaux aide aussi, c’est une contrainte dans le système pour faire croiser les gens. Si on loue un château avec 200 chambres, on se verra trop rarement voire jamais.

En une semaine, il s’est déjà passé des choses très intéressantes.

• De nouvelles personnes de différents profils qui passent régulièrement sur les canaux.
• On s’est retrouvé à plusieurs pour prendre le café un matin avant le daily, discuter un peu du projet et de sujets divers, puis on a eu notre moment improbable quand une personne nous a joué du piano.
• Un verbatim : « Je pensais qu’il manquait un canal privé. Hier soir les deux étaient pris, une personne m’a rejoint car elle en voulait un aussi. C’était bien, on était chacun focus puis on a pu discuter. Ça ne serait pas arrivé, finalement peut-être qu’il n’en manque pas ».
• Et un autre : « Bon, je viens de me relancer dans le visionnage de Kaamelott, je t’en tiens pour responsable ^^ ».

Être à côté… de la plaque

J’avais envie de raconter cette histoire parce qu’on peut facilement se planter sur la façon de travailler à distance et créer des douleurs. En ne changeant rien alors que le contexte, lui, a changé. En saturant les journées de réunions. En restant toujours seul et en ne croisant d’autres collègues qu’à travers des réunions avec d’ailleurs bien trop de monde. En voulant tout contrôler. Etc.

Le télétravail est encore assez jeune pour beaucoup d’entreprises et de personnes - c’était bien moins présent avant le covid. Je trouve intéressant de partager des expériences qui peuvent inspirer et aider d’autres équipes qui se cherchent encore dans leurs relations avec le télétravail. On n’est pas obligé d’en faire, et on n’est pas obligé de le subir non plus. On peut se l’approprier - le problème n’est parfois pas dû au fait de télétravailler mais au comment on en fait.

Chaque équipe et chaque personne a des besoins différents, il faut les prendre en compte et essayer des choses. Tentez et faites différemment, c’est l’opportunité de grandement améliorer le quotidien.

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.

J’ai été invité par Fleur Saillofest à speaker dans le meetup Beyond Scrum Mastering. Très rapidement, une trame intéressante a émergé lors de nos échanges : celle de reconnaître des problèmes au sein de l’équipe et y associer certaines pratiques tech qui pourraient aider.

Observer ce qu’il se passe dans l’équipe, entendre les râlements, les plaintes, noter les douleurs, c’est à la portée de tout le monde. J’ai pris un fil rouge avec des problèmes qu’une équipe peut rencontrer à diverses étapes de la conception du produit pour introduire certaines pratiques techs. Autour du besoin, du code, des tests, de la livraison, de l’existant, etc.

Est-ce que ce sont les seules possibilités ? Non. Mon but n’est pas d’être exhaustif ni sur les problèmes ni sur les solutions et les pratiques. Mais plutôt d’entrevoir des possibilités, de donner des billes pour ensuite aller creuser plus en profondeur avec l’équipe. Je dépose quelques brides de réflexion dans cet article qui m’ont permis de créer mon talk (slides ici).

Collaborer sur le besoin

• Les refinements sont chiants.
• On se rend compte pendant le sprint que les besoins ne sont pas clairs. Les développeurs demandent au PO des spécifications hyper détaillées avant de commencer.
• Le PO change d’avis, on fait ce qu’il y a écrit dans la story mais il dit que ce n’était pas ça qu’il voulait.

Les premiers problèmes peuvent arriver très tôt, dès l’expression du besoin, avant même d’être purement dans la tech, dans le code. On peut noter qu’il semble y avoir de l’incompréhension, qu’il y a probablement des choses implicites, des modèles mentaux différents. Que tous les membres de l’équipe ne sont pas vraiment impliqués.

Example Mapping

Une piste d’amélioration serait de faire collaborer toute l’équipe, ensemble, sur la rédaction du besoin. Je pense naturellement à l’Example Mapping. C’est un atelier qui réunit l’ensemble de l’équipe (PO, QA, Dev front/back). Le PO vient avec ses règles métiers et toute l’équipe œuvrera à créer des exemples précis pour chaque règle.

Tout le monde est impliqué, participe, et s’approprie le besoin. Les règles sont éclaircies, les exemples sont concrets et parlent à tous. L’implicite est rendu explicite, on sort ce qu’il y a de la tête du PO. Des questions peuvent émerger, avec des points à éclaircir avant de commencer le développement. On peut aussi trouver un découpage plus fin de la story.

Ce n’est plus à la seule charge du PO d’écrire un immense cahier des charges qui sera de toute façon probablement imparfait et jamais satisfaisant. Les développeurs ne restent pas passifs avec des pavés à avaler. On fait jouer l’intelligence collective en amont pour co-créer quelque chose de meilleur.

Collaborer sur le code / Git

• J’entends parler de branches, merge, commit, conflits, … Je suis perdu.
• C’est quoi ce git machin chose ?

Je dédierais un article pour vulgariser l’utilisation de git qu’en ont les développeurs. Je me limiterais à quelques lignes ici pour comprendre l’origine de certains problèmes. Git est un outil pour gérer les versions du code source.

Un développeur va créer un commit avec des changements ; c’est une copie à un instant T du code. Il va travailler sur une branche ; c’est un espace indépendant, avec ses propres copies.

Au bout d’un moment, lorsqu’il aura terminé, il va vouloir merge ; il veut réunir son travail réalisé sur sa branche (dans son espace indépendant) vers la branche principale (l’espace commun). Pour cela, il va ouvrir une Pull/Merge Request et demander à quelqu’un de faire de la revue de code ; une personne va relire toutes les modifications, pour approuver ou faire des retours.

Au moment de réunir, il peut y avoir des conflits ; dans son espace, il a modifié des zones qui ont aussi été modifiées sur l’espace commun. Il faudra résoudre ces problèmes afin de pouvoir rassembler les travaux. Qu’est-ce qu’on garde ? Qu’est-ce qui n’a plus de sens ? Qu’est-ce qu’il faut adapter ?

Plus longtemps on travaille sur une branche (dans son coin) et plus on attend pour réunir avec la branche principale (avec les autres), plus on augmente les problèmes. Par exemple, la quantité de changements et le temps qui s’allonge augmentent le risque de conflits et demandent une plus longue revue de code.

Collaborer sur le code / Revue de code

• J’en ai marre de devoir refaire plusieurs fois mon code après des aller-retours sur la code review.
• Les développeurs se plaignent que les revues de codes sont longues à faire et pas intéressantes.
• On attends longtemps avant qu’un autre développeur fasse la revue de code.

Ahhh, la revue de code, serait-ce le mal du siècle des développeurs après le mal de dos ? J’exagère un peu - j’avais envie d’écrire cette tournure humoristique - mais j’ai tout de même souvent observé des symptômes autour de la revue de code. Il faut dire aussi que c’est une pratique qui s’est très largement répandue dans les équipes. Pour autant, elle n’est pas toujours bien appliquée et elle vient avec son lot de contraintes.

Par nature, la revue de code via une Pull/Merge Request est asynchrone - la relecture arrivera un temps après la demande, qui nécessitera des changements qui seront faits un autre temps après, et ainsi de suite. Il y aura des changements de contexte, de la part du relecteur et de l’auteur. Et on sait que les changements de contexte nuisent à la productivité. On est interrompu, on sort constamment du flow (qui est long à trouver).

Le feedback est tardif. La revue est très souvent ouverte lorsque la story est entièrement terminée (rappel git : quand on veut réunir nos changements avec la branche principale). Les changements seront plus coûteux. La revue est parfois bâclée. Certains lisent rapidement en diagonal parce qu’ils n’ont pas le temps ou que ça ne les intéressent pas. D’autres vont pinailler, mais seulement sur des points insignifiants.

Ce peut être un goulot d’étranglement qui allonge la durée nécessaire pour livrer une fonctionnalité. C’est marquant lorsqu’il y a beaucoup de développeurs ou lorsque la responsabilité de la revue n’est donnée qu’à une poignée de personnes (par exemple, seul le lead/référent/manager).

Bien sûr, ce n’est pas tout noir. La revue de code peut être bien faite et a pour sa défense deux principaux bénéfices : c’est une occasion de donner du feedback pour améliorer le code et réduire les bugs, et c’est une façon de partager de la connaissance en lisant le code d’un autre.

Ok, on parle de feedback et d’apprentissage, comment pourrait-on faire mieux ? Avec un échange direct, temps réel. Avec de la mise en pratique plutôt que de la lecture passive. Avec du Pair Programming et du Mob Programming. On forme une équipe, on est ensemble, on peut faire mieux sur la collaboration. Les process de Pull/Merge Request ont davantage de sens dans le monde de l’open-source où les personnes ne se connaissent pas, ne travaillent pas ensemble, où il faut contrôler.

Pair Programming

Le Pair Programming est une pratique qui va permettre une réelle collaboration de deux personnes. On se met ensemble, sur un même problème, avec un seul ordinateur, en même temps. On échange pour trouver la solution et écrire du code. On échange pour s’améliorer en continu. Il y a une réflexion commune, deux cerveaux qui vont se challenger.

Ici, le feedback est immédiat. Je propose au plus tôt une autre approche de conception à mon pair. Je découvre une fonction plus performante au moment où j’écris ma ligne de code grâce au conseil de mon pair. On repère ce bug pendant qu’on développe la fonctionnalité ensemble. Maintenant tout de suite, pas après 5 jours de travail.

La transmission de connaissances, autant technique que fonctionnelle, est forte. Les deux développeurs travaillent ensemble au même moment. Ce meilleur pattern pour faire le traitement, je le découvre en direct voire je le mets en place moi-même. On donne en effet le clavier au non-sachant, afin de le faire pratiquer tout en le guidant. Ce scope fonctionnel, on l’aura co-créée, je le comprendrais, mon pair n’est plus le seul de l’équipe à pouvoir y travailler. C’est très efficace pour onboarder un nouvel arrivant aussi.

C’est en ça que la pair programming est puissant et ne divise pas l’efficacité par deux, il faut voir au-delà de “deux ressources qui travaillent sur un seul problème”.

Mob Programming

Le Mob Programming se trouve un cran après le Pair Programming : c’est tout un groupe qui va collaborer, en même temps, sur un seul et même problème, avec un seul ordinateur. L’intelligence collective va mener à une meilleure compréhension du problème et à une meilleure conception de la solution. Encore une fois, ce n’est pas simplement grouper un tas de personnes pour qu’elles regardent un seul développeur tout faire.

Le problème et les solutions sont discutés et challengés. Le groupe entier s’approprie le code et la fonctionnalité, tout le monde avance ensemble. On peut arriver à tacler des problèmes très complexes. Il y a une très forte transmission de connaissances et de compétences. C’est tout un groupe qui apprendra, en pratiquant, cette nouvelle technique ou cette fonctionnalité.

Note : on parle d’avoir un seul ordinateur, un seul clavier en pair et mob programming. C’est parfaitement compatible à distance avec des solutions de partage d’écran, de contrôle du clavier, de code collaboratif.

Collaborer sur le code / Conflits

• Le dev est terminé localement mais ça met beaucoup de temps à être livré car on a plein de conflits.
• La fonctionnalité marche sur ma branche mais maintenant que c’est mergé c’est cassé.

Intégration Continue

Parfois, quand on parle d’Intégration Continue, on entends Jenkins, gitlab-ci, pipelines, machine de builds, etc. Ce n’est pas ça, l’Intégration Continue. Tout ça, ce sont des outils. C’est du comment.

L’Intégration Continue, c’est d’abord un principe, une attitude. C’est rassembler très souvent les changements sur la branche principale (intégrer continuellement). On partage à tous nos changements plusieurs fois par jour ; plutôt que d’attendre de tout finir et de rassembler après 8 jours de travail intense.

Qu’est-ce que ça apporte ? Un cercle vertueux. On va faire de plus petites étapes pour rassembler plus souvent. On va faire de meilleurs tests automatisés pour s’assurer que tout est bon. Naturellement, on aura moins de conflits et de problèmes avec de petites modifications ayant une durée de vie courte.

Pair/Mob Programming

On l’a vu précédemment, le Pair et le Mob Programming permettent une réelle collaboration de plusieurs personnes. La communication est meilleure, puisqu’elle est immédiate et continue. Il y a moins de travaux simultanés en cours, puisque les développeurs se réunissent pour travailler sur le même sujet. Tout ça contribue à diminuer les risques de conflits et de problèmes de merge.

Écrire le code

• On a fait évolué l’écran recherche, et on a vu plus tard en prod que la logique métier du compte est complètement KO.
• On planifie de passer une après midi sur l’écriture de tests, on fait comment pour le prendre en compte dans la vélocité ?

Tests Unitaires

Il est important de clarifier ce que sont les tests unitaires et pourquoi on en écrit. Très simplement, un test unitaire est un test automatisé d’un scénario fonctionnel. C’est quelque chose qui vérifie que du code se comporte comme prévu, automatiquement, sans intervention humaine. C’est un programme qui lance un autre programme pour vérifier ce qu’il se passe dans différentes conditions.

On parle de comportement, de scénario fonctionnel : quand on écrit un test unitaire, on veut s’assurer de bien retranscrire le métier. C’est en ça qu’il est très important et utile pour le business, et que ce n’est pas seulement un élément technique.

Progressivement, on créé un filet de sécurité pour éviter certaines régressions. On diminue le risque d’avoir des bugs en production : on aura un feedback immédiat, pendant le développement, si une règle métier est cassée après un changement dans le code.

C’est au moment où l’on change le code que l’on sait si on altère involontairement le comportement, pas plusieurs jours après. Ce qui fait que les tests unitaires jouent un rôle essentiel au Refactoring, pour améliorer le code sereinement.

Test-Driven Development

Quand on écrit un test, une bonne pratique est de le faire au plus près du moment où l’on a écrit le code, et non pas bien après une fois que tout est terminé. Pourquoi ? Parce que c’est plus coûteux et difficile de le faire après ; le code n’ayant pas forcément été conçu pour être testable. Et parce qu’on passe à côté d’un bénéfice important : se faire guider par le test.

Et c’est la philosophie du Test-Driven Development. Ce n’est pas “écrire le test en premier” (c’est du comment). C’est se faire guider par les tests et par le métier. On définit le comportement que l’on veut obtenir (le test) puis on fait émerger la solution et on l’améliore.

On a une boucle de feedback extrêmement rapide. Quand on développe la solution, le test nous indique en quelques millisecondes si le comportement voulu est bien retranscrit.

À noter que l’écriture des tests unitaires et la pratique du TDD font partie intégrante du job de développeur et que ce n’est pas forcément plus long de tester. Au contraire, ça nous aide. C’est à faire dès qu’il y en a le besoin, en continu, il n’y a pas de permission à demander, de journées à dédier.

Livrer

• C’est douloureux de livrer, c’est long, il y a un tas de process et d’actions à faire…
• On va s’assurer d’avoir suffisamment de choses dans la release pour livrer. C’est long alors il faut que ça vaille le coup.
• On ne livre pas le vendredi. On ne peut rien modifier en août et fin décembre. On a un code freeze pendant les périodes avec beaucoup de vacances.

Automatisation

Créer une archive de l’application et l’envoyer sur un serveur, générer le fichier de traduction à partir d’une feuille Excel, remplacer toutes les majuscules d’un fichier brut par des minuscules et le transformer en JSON, … Ce sont des exemples de tâches manuelles qui gagneraient à être automatisées.

La bonne nouvelle ? Un développeur est bien placé pour automatiser, il est capable d’écrire du code pour créer un programme qui va effectuer ces tâches. Une fois créé, il n’y a plus qu’à exécuter ce programme et la tâche sera réalisée (souvent) immédiatement plutôt que de prendre trop de temps à une personne. On s’enlève au passage le risque d’erreur humaine : le programme fera toujours la même chose, il ne va pas oublier une ligne, il ne va pas se tromper de caractère, etc.

Outre l’efficacité, je trouve que c’est bien plus intéressant à faire. On conçoit un programme, on réfléchit plutôt que de répéter des tâches rébarbatives.

Livraison Continue

Le principe est simple, chaque changement sur la branche principale est livré. C’est livré dans un environnement de staging/test/preprod, ou même de production, mais ce n’est pas déployé. Ce n’est pas encore dans les mains des utilisateurs.

Autrement dit, avec la Livraison Continue, il suffit d’un simple bouton pour déployer aux utilisateurs, il n’y a pas besoin d’autres interventions. Tout est déjà prêt, on est capable de déployer sur demande. Plusieurs fois par semaine, jour, heure, etc.

Ça ne veut pas dire qu’on va forcément livrer chaque heure. Si on est capable de livrer toutes les heures, on est capable de livrer quand on veut. Et c’est ça que l’on recherche. Le déploiement devient un non-sujet. On pourra bénéficier des avantages de livrer souvent et rapidement de petits incréments, dès que cela fait sens.

Pour livrer en continu, on va mettre en place certains outils, on va automatiser des tâches, et on va s’atteler à toujours avoir un code dans un état déployable.

Déploiement Continu

Ici, on va un cran plus loin : tout est automatisé, il n’y a plus aucune intervention humaine. Chaque modification sur la branche principale est déployée en production et arrive directement dans les mains des utilisateurs.

En mettant en place la Livraison Continue ou le Déploiement Continu, on entre dans un cercle vertueux de pratiques. On se concentrera davantage sur la qualité, sur les tests automatisés, sur la création de petits incréments, sur l’activation à distance de fonctionnalités, … plutôt que sur des pratiques contraignantes comme mettre un freeze de code, avoir une semaine de tests de non-régression, avoir 4 niveaux de validations de chefferie, etc. Ce qui fera livrer moins souvent, donc il faudra faire encore plus attention, donc livrer moins donc faire plus attention, et ainsi de suite, un cercle vicieux de peur et de contrôle.

Améliorer un existant

• *On a des problèmes de qualité dont on n’a jamais le temps de s’occuper. *
• Mon équipe veut négocier un sprint ou deux de refactoring mais je ne sais pas quelle valeur ça va apporter.
• J’ai un développeur qui fait du refactoring depuis 3 mois, c’est pas encore fini mais il avance.

Refactoring

Faire du Refactoring, c’est changer le code sans casser son comportement observable. On améliore le code dans le but de mieux le comprendre ou de faciliter le changement, par exemple. Le code fera toujours la même chose. Si je fais du refactoring sur une fonctionnalité de recherche, elle fera toujours de la recherche, ni plus, ni moins.

Autre aspect très important du refactoring : on avance par petites étapes. On enchaîne une série d’améliorations, de petites étapes que l’on peut partager régulièrement. Le projet est toujours dans un bon état, on peut s’arrêter à tout moment.

C’est différent de “tout refaire”, à ne pas confondre avec la réécriture. Ce n’est pas ce fameux chantier de 3 mois en tunnel où rien ne fonctionne entre temps. Le refactoring demande de la discipline et des compétences.

Refactoring opportuniste

On fait du refactoring quotidiennement, toutes les occasions sont bonnes. J’ouvre un fichier où je vais devoir travailler, mais le changement est difficile ? Le code est legacy ? J’en profite pour faire un petit refactoring en amont plutôt que d’empirer. On peut évoquer la règle de Boy Scout :

Toujours laisser le code dans un meilleur état que celui dans lequel vous l'avez trouvé.

On préférera agir régulièrement et de manière opportuniste plutôt que de bloquer des jours/semaines dédiés au refactoring. Tout comme les tests, ça fait partie intégrante du job de développeur. Il est important de faire du refactoring régulièrement et de se former. D’ailleurs, au lieu de bloquer des jours pour faire du refactoring, peut-être le transformer en un temps pour se former et s’améliorer dans les techniques de refactoring ?

Théorie de la vitre brisée

On veut faire du refactoring régulièrement pour améliorer le code continuellement. On veut éviter que la situation ne s’empire, on veut y remédier au plus tôt. La théorie de la vitre brisée est intéressante pour expliquer pourquoi on veut agir vite et régulièrement.

Prenons par exemple une maison avec une fenêtre brisée. La théorie nous indique que si on ne fait rien, on laisse penser que la maison est à l’abandon. On va alors attirer et cumuler d’autres problèmes, des graffitis, de nouvelles fenêtres brisées, etc. Un cercle vicieux démarre et qui ira au-delà de la maison, apportant plus de criminalités dans le quartier.

Il faut remédier aux problèmes au plus vite, avant qu’ils ne soient trop nombreux. Un quartier où les maisons sont constamment bien entretenues attirera moins les problèmes. C’est la même chose avec le code, on va vouloir rester dans un état d’esprit de qualité.

Méthode Mikado

La méthode mikado est très utile pour faire du refactoring. C’est une méthode pour effectuer de grands changements avec de petites étapes. On veut atteindre un objectif, qui peut être ambitieux, on ne sait pas encore comment y aller, mais on va construire ce chemin progressivement.

On va effectuer une suite de petites expérimentations. Quand une expérimentation réussie, on a avancé vers notre objectif, avec une petite étape. Quand une expérimentation échoue, on revient en arrière, on a appris quelque chose, et on découvre qu’il faut effectuer une autre petite étape nécessaire en amont. On dessine d’ailleurs un graphe pour visualiser notre progression et nos pré-requis.

De fait, on est toujours dans un état fonctionnel, on peut s’arrêter à tout moment. On n’aura peut-être pas atteint l’objectif, mais ce sera mieux, on sera plus proche de la fin, on aura réalisé quelques petites étapes, et ça fonctionnera toujours.

Bref

On a vu un ensemble de pratiques tech reconnues dans l’industrie. On a vu comment elles peuvent aider dans certains problèmes. Et même au-delà. Ce sont des pratiques pour améliorer le quotidien de l’équipe et devenir meilleur dans la technique et dans le business.

On a aujourd’hui le recul nécessaire et les études pour voir la corrélation entre la performance technique et business. Pour répondre rapidement aux besoins de l’utilisateur, on a besoin de pouvoir livrer rapidement. Changer facilement le code permet de changer facilement de direction fonctionnelle.

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 :)

Oui, je fais allusion au pair programming. Mais avant d’en parler, plongeons-nous dans une histoire. Une histoire que j’ai déjà vécu et que vous avez probablement aussi vécu. Je dirais même que beaucoup ont vécu, d’un côté de la revue ou de l’autre.

Cette histoire vous est-elle familière ? À quel point la vivez-vous ? Vous en êtes-vous déjà rendu compte ? La review est-elle douloureuse pour vous ou votre équipe ? Prenez le temps de vous poser des questions.

Ce que l’on peut observer

Une grande partie du travail est refait. Perceval ayant créé quelque chose qui ne convient pas, du code est jeté. C’est du temps en partie perdu. De plus, la durée de la tâche s’allonge : qui dit suppression dit ré-écriture. Perceval a dû reprendre son travail avec une autre manière de faire. Les chances d’avoir des conflits à résoudre pour merge augmentent, leurs complexités aussi.

Perceval a passé beaucoup de temps tout seul et n’a eu le premier feedback que très tardivement - une fois qu’il pensait avoir terminé, ce qui augmente le coût de re-travail. Arthur a également mis du temps à faire la revue car il y avait beaucoup de code à lire.

Les discussions sont à l’écrit, et en décalées. La revue est ouverte, plus tard des commentaires sont ajoutés, plus tard des retours sont effectués, et ainsi de suite. Le temps d’attente peut être long. La tâche met plus de temps à être terminée.

À chaque aller-retour, il y a un changement de contexte. La personne (auteur ou lecteur) doit arrêter ce qu’elle était en train de faire, doit se plonger dans la revue, puis se remettre sur son ancienne tâche avec la nécessité de se re-plonger dans ce qu’elle faisait. Ce temps n’est pas négligeable.

Et que ressent Perceval ? Quand il apprend qu’il doit tout refaire. Quand il lit les commentaires d’Arthur, sujet à interprétation, pouvant être pris personnellement.

Ce que l’on peut faire

On communique davantage. On donne du feedback tôt et régulièrement. On collabore. Perceval et Arthur peuvent échanger dès le début de la tâche, pendant, et même à la fin lors de la revue. Ils peuvent la faire ensemble sur le même poste. Et soyons fous, ils peuvent se mettre au pair programming. Ça y est, on y vient.

Qu’en pensez-vous ? Remémorez-vous la première histoire.

En travaillant de paire, le feedback est immédiat et continu. Arthur accompagne en temps réel Perceval. Il n’y a plus d’aller-retour ou d’échanges à l’écrit, ni d’attente, ni de changement de contexte. Il n’y a même plus besoin de faire de code review, chaque retour a été pris en compte sur le moment et le résultat est de meilleure qualité. Avec le pair programming, la revue de code est poussée à son extrême : le binôme en fait tout le long, à chaque instant.

Les échanges sont plus humains et plus riches. Chacun apprend, partage. Chacun challenge et améliore le code écrit. Chacun comprend le code et la fonctionnalité - la propriété est collective. Les bénéfices du pair programming sont multiples. Alors pourquoi attendre ? Une heure, une journée, une fonctionnalité de bout-en-bout, … Lancez-vous. À votre rythme, mais lancez-vous.

Testez, observez ce qui change, prenez du feedback. Apprenez à faire du pair programming, acceptez au début de ne pas savoir faire, améliorez-vous. Et appréciez :)

Post-scriptum du prêtre : toute ressemblance avec des personnes existantes ou ayant existé dans la légende arthurienne ne saurait être que fortuite. Ou pas. Je suis en manque de film Kaamelott.

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.

C’est quelque chose que j’utilise régulièrement avec mon binôme. Sur la demande de l’un ou de l’autre. Je m’en sers beaucoup pour accompagner, partager mes connaissances, donner du feedback. On a des cas concrets pour échanger, confronter des idées et résoudre des problèmes.

Et puis un jour je me suis dit, tiens, et si on se fixait un moment dédié et régulier pour faire du pair programming ? En conservant toujours la possibilité de le faire spontanément si besoin. L’un n’empêche pas l’autre. Je l’ai proposé à mon collègue et on s’est lancé. On a essayé une fois par semaine, un créneau récurrent inscrit dans l’agenda. On a tenu chaque séance depuis le début. Aujourd’hui, j’ai eu envie de revenir sur cette expérimentation et sur ce que ça nous a apporté.

Pourquoi cette envie de ritualiser ?

Printemps 2020 rime, malheureusement, avec la pandémie de Covid-19. Lorsque l’on a été confiné, mon équipe est passée de quelques rares jours de télétravail par mois à du full remote. Je voulais garder un lien fort de partage avec mon binôme. Sur notre lieu de travail, nous étions côte à côte. Il était aisé de tourner l’écran de manière spontanée et de dire « Hey, qu’est-ce que tu en penses ? » ou « Je suis bloqué ici, tu peux regarder avec moi ? ».

À distance, j’avais peur que l’on perde ça. On ose peut-être moins. Ça demande plus d’effort. Plus de synchro. Il faut demander et appeler. Je pense qu’il peut y avoir une peur de déranger, on ne sait pas ce que l’autre fait à ce moment, on ne le voit pas. La raison première était donc de garder un lien. En ritualisant, je savais que l’on avait un créneau réservé sur nos agendas pour le faire.

Ce que j’en attendais également, c’était de partager encore plus. En faisant régulièrement du pair programming, au moins une fois dans la semaine, je voulais accentuer mon accompagnement. Avoir plus de moments où je pouvais transmettre et échanger.

Qu’est-ce que j’ai observé ?

Beaucoup de bonnes choses. J’ai même envie de dire que des bonnes choses. J’ai été agréablement surpris par chacune de nos séances. On a, à plusieurs reprises, dépassé notre créneau et continué naturellement, parce que c’était utile, parce que ça apportait de la valeur. On s’est beaucoup entraidé avec nos différentes connaissances du métier et du code. La confrontation régulière des idées a permis d’avancer plus vite sur des sujets parfois complexes.

J’ai remarqué un effet canard en plastique. Expliquer son problème à quelqu’un d’autres aide à mieux le comprendre et à trouver une solution. Donc le faire régulièrement (avec plus de pair programming) aide à trouver plus souvent et plus rapidement des solutions. C’est très bénéfique.

Une de mes craintes au départ était « est-ce qu’on aura à chaque fois des sujets adapté au pair programming ? ». En fait, oui. Ce n’est pas du tout un problème. Un jour, j’étais sur une correction de bug assez mystique. Je n’étais pas très avancé dessus et je n’avais pas de pistes intéressantes. Je pensais que ce ne serait pas très intéressant pour le créneau de pair programming qui allait démarrer.

Mais je me trompais. Ce fut l’une des sessions les plus utiles. Avec nos deux cerveaux et nos échanges, on a avancé extrêmement vite sur ce sujet. On a fait du pair programming l’après-midi entière et on a pu corriger ce bug. On a été très productif. Beaucoup plus que si j’étais resté seul.

En plus du gain de productivité et de la résolution de problèmes, j’ai pu beaucoup plus transmettre et accompagner mon binôme avec ces séances de pair programming régulières. Je trouve que c’est un excellent moyen d’apprendre les uns des autres, de guider, d’expliquer, d’essayer. On fait des choses concrètes, ensemble. On code et on échange en direct.

Enfin, une autre conséquence que j’ai observée avec l’augmentation de pair programming est la réduction du temps passé à faire du code review. Elles sont moins nombreuses et plus rapides. Plus on écrit du code ensemble, moins il y a besoin d’un processus où on le relit. Et c’est une bonne chose je trouve. Je préfère faire davantage de pair programming que de code review. Et si on arrêtait les revues de code ?

Le pair programming nous fait collaborer. On partage la propriété du code (collective code ownership), on est capable de comprendre chaque partie. C’est interactif. C’est en direct. Les code reviews sont asynchrones. On échange à l’écrit. On donne du feedback bien après l’écriture du code.

Et maintenant ?

Je compte bien conserver ce rituel et continuer à avoir un créneau dédié au pair programming. Même si le confinement est terminé et que l’on retourne partiellement au bureau, j’aime beaucoup tout ce que le pair programming nous apporte. Le fait de le ritualiser permet d’en faire plus régulièrement. Ca nous apporte un cadre.

Je songe à augmenter notre « temps minimum » de pair programming par semaine. Soit en augmentant la durée du créneau, soit en ayant deux créneaux dans la semaine. Je réfléchis aussi à une variante. Au début d’un sprint, choisir une story et décider de la faire entièrement en pair programming. Du début à la fin.

Une autre idée qui me semble intéressante serait de faire du pair programming avec une autre spécialité de temps en temps (on est organisé en feature team, il y a des développeurs Android, iOS et backend dans l’équipe). De cette manière, on obtiendrait plus de compréhension sur les autres plateformes. On irait également plus loin dans la pluridisciplinarité. J’ai pu le faire à deux reprises au début de l’année avec un développeur Android pour comprendre un problème commun, ce fut très utile.

Bref

L’expérimentation de ritualiser le pair programming s’est révélée très positive. Nous en avons tiré beaucoup de bonnes choses. Du partage, de l’accompagnement, de la collaboration, collective code ownership, etc. Tout ça régulièrement. Nous étions très productifs dans ces moments-là. Les discussions autour de l’écriture du code ont apporté des idées, des résolutions de problèmes, de l’apprentissage.

Je recommande vivement de faire davantage de pair programming. Avoir un créneau dédié peut être un moyen d’y parvenir. Essayez. C’est simple à mettre en place et très efficace. Si vous n’en faites pas du tout, lancez-vous. Si vous en fait de temps en temps, tentez de fixer un créneau. Vous pouvez commencer petit, avec une heure par semaine par exemple. Décidez d’un moment, officialisez-le dans l’agenda, et tenez le.

Et vous, à quel point faites-vous du Pair Programming ? Et comment ?

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.