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 ?