The Name Game: A surprising exploration of flow, focus, and team dynamics en fr

The Name Game: A surprising exploration of flow, focus, and team dynamics

How can something so simple go so wrong — and teach us so much?
In this fast-paced and deceptively light activity, participants are invited to take part in what seems like a harmless team challenge. But as the pressure mounts and interactions pile up, unexpected patterns emerge. This game creates the perfect setup for powerful insights around collaboration, task design, and delivery flow.
Come ready to play, observe, and reflect. You’ll leave with a few laughs, a few “aha!” moments — and a fresh look at the hidden dynamics that shape your teams’ performance.

Facilitator Spoiler (not to include in the program description):
This game sheds light on a widespread organizational dysfunction: trying to move everything forward in parallel — often at the cost of real effectiveness. Through a deceptively simple setup — a developer asked to write down the names of several "clients" according to their priorities — participants experience firsthand the hidden cost of forced multitasking: constant context switching, broken flow, and mounting delays despite good intentions.
The activity, supported by concrete metrics, allows the group to compare two modes of working: one where everything is tackled at once, and another constrained by limited WIP. The result? A collective, data-driven realization of how organizational choices impact delivery — and practical insights into how to work smarter.

Le Name Game : une exploration inattendue du flux, de la concentration et des dynamiques d’équipe en fr

Comment un exercice si simple peut-il dérailler… et nous en apprendre autant ?
Dans cet atelier rythmé et en apparence léger, les participant·e·s relèvent un petit défi d’équipe en apparence anodin. Mais très vite, la pression monte, les interactions s’accumulent… et des comportements inattendus surgissent. Cette activité ludique est un puissant déclencheur de réflexions sur la collaboration, la structure du travail, et les dynamiques de flux.
Un atelier vivant, participatif et accessible — qui déclenche autant de sourires que de prises de conscience.

Spoiler facilitateur (à ne pas dévoiler dans le programme) :
Ce jeu illustre une pathologie bien connue dans de nombreuses organisations : vouloir faire avancer tous les sujets en parallèle, au détriment de l'efficacité réelle. À travers une mise en situation aussi simple que révélatrice — un développeur devant écrire les prénoms de plusieurs "clients" en suivant leur ordre de priorité — les participant·e·s expérimentent les effets du multitâche forcé : context switching permanent, flux interrompus, et délais qui explosent malgré des intentions louables.
L’exercice, rythmé par des mesures concrètes, permet de comparer deux approches : un mode de travail "tout en parallèle" face à un mode limité par le WIP. Résultat ? Une prise de conscience nette, chiffrée et collective sur l'impact des choix d'organisation… et des pistes concrètes pour mieux faire.

Pairing is caring! en fr

When I was an Engineering Manager at CoachHub, pairing and mob programming quickly became second nature to the teams I worked with. It reached a point where I didn’t even have to advocate for it — engineers took full ownership of how, when, and how often they paired. They adjusted the style, session length, and group size themselves — because they saw the benefits firsthand: better code, deeper collaboration, and faster onboarding.

Later, when I joined Ogury as an Agile Coach, I was surprised to face almost hostile reactions when suggesting pair or mob programming. For many, it seemed like a waste of time — something that would hurt productivity rather than help it. But as I dug deeper, I realized those concerns were valid: pairing had been misunderstood, misapplied, or imposed without context.

This talk is based on the presentation that helped me begin shifting that mindset across engineering and product teams. Aimed at Scrum Masters, Engineering Managers, team leads and engineers, it’s not just about explaining what pairing is — it’s about why it works, where it helps, and how to implement it without backlash.

You’ll walk away with:
- A deeper understanding of the real value of pair and mob programming
- Practical, battle-tested tips for introducing it with less resistance
- A human-centered perspective on collaboration, trust, and technical excellence

Whether you’re looking to bring pairing into your team — or just do it better — this talk will give you the tools (and the mindset) to make it happen.

Pairing is caring! en fr

Lorsque j’étais Engineering Manager chez CoachHub, le pair et mob programming se sont installés naturellement dans mes équipes. Les ingénieurs s’étaient totalement approprié la pratique. Ils décidaient eux-mêmes du format, du rythme, du style — parce qu’ils en voyaient les bénéfices au quotidien : code plus qualitatif, moins d'introductions de bugs, identification des angles morts plus en among, partage de connaissances, opportunités de mentoring...

En rejoignant Ogury comme coach agile, j’ai été surpris de faire face à une forte résistance. Beaucoup voyaient le pairing comme une perte de temps, un frein à la vélocité, voire une contrainte inutile. Et ces réactions étaient fondées : le pairing avait été mal compris, mal introduit, mal ou même jamais vécu.

Cette conférence est née de la présentation qui m’a permis de faire bouger les lignes. Elle s’adresse aux Scrum Masters, Engineering Managers, tech leads et développeurs qui souhaitent introduire (ou réintroduire) le pair programming de manière durable et adaptée dans leur organisation.

Vous y découvrirez :
- Les bénéfices concrets du pairing pour les individus, les équipes et les organisations
- Pourquoi il échoue parfois — et comment éviter ces pièges
- Des pratiques simples, humaines et simples à mettre en oeuvre pour vous y mettre sans forcer

Que vous soyez convaincu·e, curieux·se ou sceptique, vous repartirez avec une nouvelle perspective sur cette pratique souvent mal comprise.

Code review, fertile ground for growing your IT teams. en fr

While the "pull request" workflow has almost become the standard in the development process, this exercise is still too often seen as a judgment between peers, which can quickly turn into an ego battle to the detriment of productivity and developers' well-being.

What if we took the time to learn how to conduct more human and constructive code reviews, where the goal is primarily to produce the best possible code while allowing developers to learn from each other and improve every day?

Houston, we have a problem - An introduction to group decision-making en fr

Based on an analysis of the decision to maintain the launch of the Challenger shuttle which ended in a disaster killing its entire crew, this talk gives the first keys immediately applicable to improving the ability of a team to decide together.

Failure MUST be an option en fr

Do you remember that moment, as a developer, when you realized that the code you were writing was ACTUALLY going to production? That there wouldn’t always be someone behind you checking that what’s about to be shipped is perfectly reliable?
Usually, that realization comes hand-in-hand with a nice big bug you introduced, the kind that makes you want to hide under your desk for the rest of your life.
Sure, you survive it by swallowing your pride, but let’s be honest: it never feels great. And the real issue is… we’re going to make more mistakes.

So how are we supposed to handle that, at our own small scale? At the scale of a team? Of an organization?
That’s exactly what “Failure MUST be an option” is all about: accepting this reality and turning it into an opportunity for everyone to grow from each failure.
We’ll talk psychological safety with Amy Edmondson, “perverse incentives” with our British friends, and even NASA’s space shuttles!

In this talk, we laugh, we learn, and above all, we take a step back from failure so it stops being a blame-fest or something we sweep under the rug.
We show up as adults, and we face it — with the right culture and the right tools.

Failure MUST be an option en fr

Vous vous souvenez, en tant que développeur, de ce jour où vous avez réalisé que ce que vous codiez partait VRAIMENT en production ? Qu'il n'y aurait pas toujours quelqu'un derrière vous pour vérifier que ce qui s'apprête à être livré est parfaitement fiable ? En général, cette réalisation est très fortement liée à un bon gros bug que vous avez introduit, et qui vous a donné envie de vous cacher sous votre bureau jusqu'à la fin de vos jours. Bon, même si on survit en mettant son égo de côté, ça n'a jamais rien d'agréable. Mais le problème, c'est que des loupés, on en fera d'autres.

Du coup on fait comment pour gérer ça à notre petite échelle ? À l'échelle d'une équipe ? D'une organisation ?
C'est de cela dont on parle, dans "Failure MUST be an option", de cette réalité qu'il faut accepter, et transformer en opportunité de toutes et tous ressortir grandis de chaque échec. On parle aussi sécurité psychologique avec Amy Edmondson, "perverse incentives" avec nos amis britanniques, viagra, et même navettes spatiales de la NASA !

Dans ce talk on rit, on apprend, et surtout on prend du recul sur l'échec pour ne plus en faire une foire d'empoigne ou un truc à glisser sous le tapis. On agit en adultes, et on fait face, avec la bonne culture et les bons outils.

Houston, nous avons un problème - Une introduction à la prise de décision en groupe en fr

S'appuyant sur une analyse de la prise de décision de maintenir le lancement de la navette Challenger qui se solda par une catastrophe tuant l'ensemble de son équipage, ce talk donne de premières clés applicables immédiatement pour améliorer la capacité d'une équipe à décider ensemble.

One year in the desert - How our product team survived without a PM or QA en fr

January 2023, our product team (already deprived of a Quality Analyst) sees the departure of its Product Manager who, for budgetary reasons, cannot temporarily be replaced. As is often the case in IT, this “temporarily” will continue, for almost a year.

Taking responsibility for a new bug-prone scope already displaying no less than 70 open bug tickets, we weathered a real storm to end the year with almost no open bug tickets while continuously delivering new essential features.

During this presentation, I tell you how each member of the team went beyond the scope of their role to compensate for the absences of Product Manager and Quality Analyst. How each person developed new skills to create real resilience despite the limited number of 3 developers and ensure knowledge sharing such that very quickly, no one was essential anymore. We beat the bus factor, continually improved our processes, and created an environment of psychological safety and innovation.

It is the story of a team which, while it had all the ingredients to fail, was on the contrary able to build itself against all odds thanks to agility and psychological safety.

Feedback on how a product team without a Product Manager or Quality Analyst managed, over a year, to deliver key features while facing hundreds of bugs.

Une année dans le désert - Comment notre équipe produit a survécu sans PM ni QA en fr

Janvier 2023, notre équipe produit (déjà privée d'un Quality Analyst) voit partir son Product Manager qui, pour des raisons de budget, ne peut temporairement pas être remplacé. Comme souvent dans l'IT, ce "temporairement" va se prolonger, pendant presque un an.

Récupérant la responsabilité d'un nouveau périmètre sujet aux bugs affichant déjà pas moins de 70 tickets bug ouverts, nous avons affronté une véritable tempête pour terminer l'année avec presque plus aucun ticket bug ouvert tout en délivrant continuellement de nouvelles fonctionnalités essentielles.

Durant cette présentation, je vous raconte comment chaque membre de l'équipe a dépassé le cadre de son rôle pour palier les absences de Product Manager et de Quality Analyst. Comment chacune et chacun a développé de nouvelles compétences pour créer une véritable résilience malgré le nombre restreint de 3 développeurs et assurer un partage de connaissance tel que très vite, personne n'a plus été indispensable. Nous avons battu le bus factor, continuellement amélioré nos process, et créé un environnement de sécurité psychologique et d'innovation.

C'est l'histoire d'une équipe qui, si elle avait tous les ingrédients pour échouer, a au contraire su se construire envers et contre tout grâce à l'agilité et à la sécurité psychologique.

Retour d'expérience sur comment une équipe produit sans Product Manager ni Quality Analyst est parvenue, durant un an, à délivrer des fonctionnalités clés tout en faisant face à des centaines de bugs.

La code review, terreau fertile pour faire grandir vos équipes IT en fr

Alors que le fonctionnement à base de "pull requests" s'est quasiment imposé comme norme dans le processus de développement, cet exercice est encore trop souvent assimilé à un jugement entre pairs pouvant rapidement dégénérer en bataille d'égos au grand damn de la productivité et la sénérité des développeurs.

Et si on prenait le temps d'apprendre à faire des revues de code plus humaine et constructives, dont l'objectif est avant tout de produire le meilleur code possible tout en permettant aux développeurs d'apprendre les uns des autres pour devenir chaque jour meilleurs ?