Me croiriez-vous si je vous disais que je faisais des Learning Hour avant même d’en connaître le concept?
J’ai toujours trouvé qu’il était important de partager nos connaissances, de s’appuyer sur le travail publié par nos prédécesseurs et d’établir des bases communes afin d’être efficace et de nous améliorer en tant qu’équipe. C’est pourquoi à un moment de ma carrière j’ai eu l’idée d’implanter des sessions d’apprentissage s’inspirant des problèmes vécus par les développeurs au quotidien. Le but était non seulement d’améliorer la qualité du code produit, mais aussi la qualité de vie des membres de l’équipe. Car on va se le dire, travailler sur du code mal structuré, ce n’est jamais hyper motivant. À ce moment, comme j’étais aussi développeur dans l’équipe, j’avais non seulement l’occasion de vivre moi aussi ces douleurs, mais aussi la chance d’inspirer le changement et de consolider les apprentissages faits lors de ces sessions dans nos projets de tous les jours. J’étais loin de me douter que ces sessions d’apprentissage avaient un nom : les Learning Hour.
C’est lorsque j’ai rencontré Emily Bache dans une formation où elle présentait la méthode Samman que j’ai eu une impression de déjà vu. Sa façon de travailler avec les équipes de développement ressemblait étrangement à ce que je faisais intuitivement: une heure d’activité dirigée suivi d’une immersion dans le quotidien de l’équipe. C’est ainsi que je suis devenu familier avec les concepts de coach technique et de Learning Hour.
À mon arrivée chez Nexapp, les Learning Hour ont été l’une des premières initiatives que j’ai soumis à notre VP Ingénierie. Ce dernier m’a encouragé à implanter cette méthode ainsi que d’autres activités complémentaires, comme les coding dojos. Dans cet article de blogue, démystifions ce qu’est un Learning Hour, comment il peut servir les équipes de développement, et ce que l’avenir réserve au Learning Hour chez Nexapp.
Selon le livre Technical Agile Coaching with the Samman method d’Emily Bache, les Learning Hour sont de courtes sessions de formation au cours desquelles les participants mettent en pratique leurs compétences de programmation et apprennent de nouvelles techniques. Pendant le Learning Hour, le coach utilise des exercices et des techniques d'apprentissage dynamiques pour enseigner la théorie et la pratique de nouvelles compétences telles que le test-driven development (TDD), le refactoring et l’identification de code smells.
Idéalement, on combine le Learning Hour avec l'ensemble working (ex. : mob programming) dans des sessions où toute l'équipe collabore avec le coach pour appliquer les mêmes techniques et compétences dans leur codebase de tous les jours.
L’objectif ultime est d’améliorer la façon dont les logiciels sont conçus! Mais selon Emily Bache, les avantages sont multiples :
Ce sont tous des éléments qui rejoignent les valeurs et la mission de Nexapp. De plus, un point important de la gestion du changement est d’y aller une étape à la fois, par petits incréments répétés constamment, en démontrant les bénéfices des nouvelles pratiques mises en place.
Les gens ne vont pas commencer à travailler différemment du jour au lendemain, mais on peut montrer des méthodologies, présenter les avantages et les situations dans lesquelles ça s’applique pour semer des graines dans la tête des développeurs.
C’est un travail de longue haleine : il faut répéter régulièrement le même discours et la même vision pour tendre vers le changement. Pour moi, le meilleur véhicule pour y arriver est le Learning Hour, puisqu’il me permet d’amener un flot continu d’apprentissages qui nous amènent vers des cycles de développement beaucoup plus courts. Et il y a tellement de trucs à apprendre et à maîtriser que de dédier une heure à la formation, c'est assurément rentable!
Chez Nexapp, le Learning Hour se déroule chaque semaine pendant une plage horaire accordée à tous les employés. Les thèmes s'adressent parfois plus aux développeurs, mais bien souvent, tout le monde peut en tirer profit. Ce sont les employés eux-mêmes qui sélectionnent les sujets en fonction de leurs intérêts et de leurs domaines d'expertise. La formule initiale du Learning Hour prévoyait 20 minutes de théorie, 25 minutes d'exercices pratiques et 15 minutes de rétrospective. Cette approche a évolué pour mieux s'adapter aux différents sujets abordés. Désormais, nous consacrons généralement une heure entière à la théorie, tout en encourageant le partage d'idées et le questionnement entre les participants.
Cette plage horaire me permet de rejoindre plus de développeurs, de designers et de product owners que mon équipe immédiate et me donne un terrain de jeu où je peux introduire une vision plus globale du développement, en plus de susciter la curiosité et le désir d'apprendre tout en s'amusant.
S’améliorer, c’est comme une quête du Graal :
Chez Nexapp, plusieurs autres initiatives d’apprentissage en continu complémentent les Learning Hour. Par exemple, nos guildes infra et tests interviennent pour creuser un sujet plus en profondeur et monter un atelier pratique. De plus, n’importe quel membre de l’équipe peut proposer un Lunch & Learn à ses collègues pour présenter une découverte qu’il a fait dans les jours précédents. Dans le cas des Learning Hour, ce qu’on cherche à avoir c’est un fil conducteur, une vision et je m'assure d’aligner les apprentissages vers nos objectifs.
Le plan général est de revoir les principes fondamentaux (ex. : smells, refactoring, tests, bases de l'infra) et d'évoluer vers des techniques plus avancées qui vont nous permettre d'avoir un cycle de développement plus court. Par exemple, le TDD, le continuous deployment, un meilleur découpage du travail à exécuter, l’ architecture évolutive et le «shift left», sont tous des techniques et principes qui vont aider Nexapp à livrer de la qualité rapidement et à garder cette vitesse de croisière avec le temps, malgré la complexité.
Bien que le plan général soit bien établi, je laisse place à la flexibilité pour répondre à des enjeux prioritaires dans les équipes, tout en insérant des notions de TDD, de refactoring et de reconnaissance de smells dans les sujets qui me sont demandés.
Déjà après quelques itérations de l’initiative, j’observe des retombées positives dans l’équipe. Plusieurs développeurs m’ont partagé avoir mis en pratique des apprentissages du Learning Hour dans leur projet. D’autres en sont simplement venus à comprendre leurs erreurs commises par le passé ou encore les «douleurs» qu’ils ressentaient dans leur quotidien, tout simplement en faisant un lien avec les bonnes pratiques proposées par le Learning Hour.
C’est normal de continuer à faire des erreurs : le but du Learning Hour n’est pas de devenir parfait et rigide. Il s’agit d’exposer les développeurs aux problèmes qu’ils pourraient vivre, leur offrir des bases auxquelles se rattacher afin de comprendre pourquoi ils devraient travailler différemment, puis les laisser expérimenter et faire des erreurs. L’objectif est de partager des solutions pour éviter de faire la même erreur deux fois et de stimuler leur sens critique. En ce sens, le Learning Hour sème donc déjà des graines vers l’amélioration continue.
Dans un premier temps, je souhaite amener les développeurs à réfléchir plus régulièrement à ce qu’ils font : pourquoi ils le font? Qu’est-ce qu’ils veulent réellement accomplir? Quels sont les paramètres à définir? Une des techniques que je préconise pour nous inciter à faire ce questionnement en continu est le TDD! Identifier le prochain petit incrément à livrer, écrire un test pour notre hypothèse, réaliser l’implémentation la plus simple, s’arrêter et améliorer le tout … Puis recommencer le cycle. Ça nous oblige à ralentir pour réfléchir et se réaligner constamment.
En révisant les bases (ex. : code smells, refactoring, design patterns, écriture de tests), mon objectif est d’ouvrir la discussion autour des pratiques et de commencer à assembler les pièces du casse-tête vers un TDD efficace. Je m’attends à passer encore plusieurs Learning Hour sur ces sujets, parce que pour reconnaître et corriger les smells, il faut en voir beaucoup, lire du code et en discuter entre développeurs.
Un des prochains sujets qui sera abordé pendant les Learning Hour se situera moins dans les techniques de travail du développeur et davantage dans la synergie avec le volet business, les designers et l’assurance qualité : comment favoriser la collaboration en continue au lieu de travailler en silo!
Et vous, connaissiez-vous les Learning Hour? Avez-vous mis en place des pratiques similaires dans vos équipes? Je suis curieux de vous entendre sur le sujet!
Le Learning Hour fait partie d’une panoplie d’activités offertes à nos développeurs pour continuer d’élever la barre de qualité dans leurs projets technologiques. En voici quelques exemples :
Tu te verrais faire partie de notre équipe de développement? Consulte notre section carrière ou écris-nous pour plus d’informations!