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

The point of this talk is to demystify failure. To stop making it a shameful taboo, which we hide as much as possible, which no one wants to talk about, when there is so much to learn from it.

Very inspired by the work of Amy Edmondson, I address what she describes as the "spectrum" of failures, which ranges from reprehensible failures to those that should be encouraged.

Failure being emotionally charged, the challenge is to make people and organizations understand that, in many cases, it is appropriate to detach ourselves from it to concentrate on the lessons learned from it: adapting a failing process, adjust a method, strengthen and propagate a practice that works well...

Rich in anecdotes and parallels with everyday life, this talk is a call for humility in front of failure, the unpredictable, uncertainty, but also a great way to spread the idea that we learn a lot by making mistakes.

Failure MUST be an option en fr

L'idée de ce talk est de démystifier l'erreur, l'échec, la défaillance. D'arrêter d'en faire un tabou honteux, qu'on cache autant que possible, dont personne ne veut parler, alors qu'il y a tant à en tirer.

Très inspiré des travaux d'Amy Edmondson, j'y aborde ce qu'elle décrit comme le "spectre" des échecs, qui va des échecs répréhensibles à ceux que l'on doit encourager.

L'échec étant émotionnellement chargé, le défi est de faire comprendre aux personnes et aux organisations que, dans de très nombreux cas de figure, il convient de s'en détacher pour se concentrer sur l'enseignement qu'on en retire : adapter un processus défaillant, ajuster une méthode, renforcer et propager une pratique qui fonctionne bien...

Riche d'anecdotes, de parallèles avec la vie de tous les jours, ce talk est un appel à l'humilité face à l'échec, à l'imprévisible, à l'incertitude, mais également un formidable vecteur de transmission de l'idée qu'on apprend beaucoup en se trompant.

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 ?