

Olivier Breda
Senior Agile Coach at Ogury
Senior Agile Coach at Ogury
Strasbourg, France
Actions
I started my career as a software developer, but I quickly realized my passion went beyond just writing code—I wanted to help teams grow, collaborate, and succeed together. Over the past 15 years, I’ve evolved from engineering roles to leadership and coaching, working with companies like Apiday, CoachHub, Merck Millipore, and Crédit Mutuel.
As a Head of Engineering and Agile Coach, I’ve restructured teams, improved hiring processes, and helped organizations embrace agility. My focus has always been on fostering psychological safety, enabling continuous improvement, and making sure teams have the right environment to thrive.
Beyond my day-to-day work, I love sharing my experience—whether it’s mentoring future leaders, speaking at conferences, or coaching teams through change.
J'ai commencé ma carrière en tant que développeur logiciel, mais j'ai rapidement réalisé que ma passion allait au-delà de l'écriture de code : je voulais aider les équipes à se développer, à collaborer et à réussir ensemble. Au cours des 15 dernières années, j'ai évolué de rôles techniques vers des fonctions de leadership et de coaching, en travaillant avec des entreprises comme Apiday, CoachHub, Merck Millipore et Crédit Mutuel.
En tant que Head of Engineering et Agile Coach, j'ai restructuré des équipes, amélioré les processus de recrutement et aidé les organisations à adopter l'agilité. Mon objectif a toujours été de favoriser la sécurité psychologique, de permettre l'amélioration continue et de m'assurer que les équipes disposent du bon environnement pour prospérer.
Au-delà de mon travail quotidien, j'adore partager mon expérience, que ce soit en mentorant des futurs leaders, en intervenant lors de conférences ou en coachant des équipes lors de changements.
Area of Expertise
Topics
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 ?
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top