← BibliothèqueToutes les vidéos
Tech.Rocks Summit 2022
Comment travailler en équipe en 2022 ?
- Alexandre Victoor (CTO, Comet Meetings)
Tech.Rocks Summit 2022 · 8 décembre 2022 · 20 min · en français
Résumé
Le monde du travail est en pleine mutation et les défis ne manquent pas pour les managers IT : comment construire une équipe soudée quand le full remote est généralisé, et garder les collaborateurs engagés à l'heure de la « grande démission » ? Alexandre Victoor, CTO de Comet Meetings, revient sur « Extreme Programming Explained », livre paru il y a une vingtaine d'années qui, sans une ligne de code, regorge de conseils pour bâtir une équipe prête à relever les défis d'aujourd'hui.
L’essentiel
Alexandre Victoor, CTO de Comet Meetings, relit « Extreme Programming Explained » de Kent Beck comme un livre sur le lien social et montre comment son équipe en applique les principes, y compris à distance.
Pour réfléchir à la cohésion, au rythme et aux pratiques de collaboration d’une équipe de développement, en particulier en travail hybride.
Les idées clés
- Le cœur d’XP, c’est le lien social. Au-delà des pratiques techniques devenues courantes (refactoring, tests, intégration continue), le livre porte selon lui sur l’importance d’équipes soudées, élargies au produit, au design et au business. Pour une équipe en partie à distance, il utilise un logiciel de bureau virtuel, caméra allumée, efficace contre le sentiment d’isolement sans remplacer les rencontres en présentiel. à 2:23
- Communication, respect, feedback. Il recrute avec une session de travail de deux heures sur un projet fictif avec deux ou trois membres de l’équipe ; pour les choix structurants, il donne la parole à tout le monde, en priorité aux juniors ; et il préfère un feedback immédiat, en travaillant à plusieurs devant un écran, à la revue de code tardive des pull requests. à 7:32
- Un rythme d’une semaine tenable. Depuis trois ans, l’équipe travaille en itérations d’une semaine, avec chaque vendredi après-midi un bilan, une démo, un échange de feedback et les priorités de la semaine suivante, business compris. Pour tenir ce rythme : pas d’heures supplémentaires, du « slack time » le lundi matin pour essayer de nouveaux outils, et une recherche permanente de simplicité. à 9:14
Questions pour votre équipe
- À quel moment nos développeurs reçoivent-ils du feedback sur leur code : pendant ou après ?
- Qui s’exprime en premier lors de nos choix techniques structurants ?
- Quel temps réservons-nous pour essayer de nouveaux outils sans pression de livraison ?
Il s’agit d’un talk court, fondé sur l’expérience d’une seule équipe sur trois ans. L’intervenant est CTO de Comet Meetings, qui accueille l’événement et dont il vante les lieux ; le logiciel de bureau virtuel cité est un choix de son équipe. Le titre d’origine, préfixé « [Comet Meetings] », suggère une session partenaire. Aucun chiffre ne mesure les effets décrits ; la question du passage à l’échelle n’est abordée que brièvement en réponse à la salle.
Chapitres
Summary
The world of work is changing fast and IT managers face many challenges: how do you build a close-knit team when full remote is the norm, and keep people engaged in the era of the "Great Resignation"? Alexandre Victoor, CTO of Comet Meetings, revisits "Extreme Programming Explained", a book published some twenty years ago that contains no code but plenty of advice for building a team ready for today's challenges.
Thèmes : Management & organisation
Transcript complet
Transcription automatique, à relire : les noms propres peuvent être mal orthographiés.
Alors, je vous l'avais mentionné en introduction, vous avez remarqué, on est dans un lieu assez magique, pour ceux qui ne le connaissaient pas, c'est le Comet Meetings qui favorise justement les méthodes de travail collaboratives et c'est exactement ce que va nous expliquer son CTO, Alexandre Victoor, que je vous demande d'accueillir. Salut Alexandre! Comment ça va? On va vous expliquer des petits marqueurs pour qu'on soit bien, pour que ceux qui nous regardent puissent profiter de vous ce matin, de ce que vous nous racontez. Je le disais, le collaboratif est au cœur de la tech et de plus en plus au cœur même des organisations qui se développent. Même si ce mode collaboratif a été un peu chahuté aussi par le Covid, chahuté dans le bon sens ou dans le mauvais sens en fonction des organisations. Les questions que je vais vous poser, vous allez pouvoir nous ouvrir l'appétit là-dessus, c'est qu'est-ce qui les facilite, qu'est-ce qui les freine, et je crois que maintenant, c'est à vous de jouer. Merci. Bonjour à tous.
Alors aujourd'hui, moi, je vais vous parler de quelque chose qui me tient à cœur. Je vais vous parler de quelqu'un qui a changé ma vie. Cette personne, c'est ce monsieur. Peut-être que parmi vous, il y en a qui le reconnaissent. Ah, il y a quelqu'un quand même. Alors ce monsieur, c'est Ken Beck. Ken Beck, c'est un visionnaire. C'est l'un des signataires du manifeste Agile. Et c'est surtout l'auteur de ce livre, il y a plus de 20 ans, Extreme Programming Explained. Alors si vous l'avez déjà lu, Vous savez que ce livre a changé votre vie. Si vous ne l'avez pas encore lu, il a déjà changé la vôtre parce qu'il a bouleversé notre industrie. Ce livre n'est pas très épais, il fait environ 200 pages, mais vraiment c'est un concentré d'idées novatrices. La seule chose qu'on peut reprocher à Ken Beck, c'est le titre du livre, parce que Extreme Programming Explained, c'est long, ça ne se prononce pas facilement.
Extreme Programming, la plupart des gens vont plutôt dire XP. Et puis Extreme, ça fait peur. Et Programming, vraiment, ce n'est pas très bien choisi. Il n'y a pas une ligne de code dans tout le bouquin. Et voilà, il y a vraiment plein de choses dans ce livre. On trouve notamment, dès la première édition, en 1999, les notions de convention de code, de design, de refactoring en continu. Et puis il y a aussi les prémices du Test Drive and Development, du TDD, avec le Test First. En fait, il y a déjà toutes les bases d'un mouvement qu'on allait appeler plus tard le Software Craftsmanship. Mais ce n'est pas tout. Ken Beck nous parle il y a plus de 20 ans de tests, d'automatisation, d'intégration continue, de déploiement tous les jours, de déploiement incrémentaux. En fait, il nous parle déjà de continuous delivery. Alors moi franchement, je trouve ça épatant. Il y a vraiment plein d'idées. Il y a vraiment plein d'idées dans ce bouquin. Il y en a certaines qui sont maintenant mainstream, qui sont considérées quasiment comme du bon sens.
Mais ce qui est encore plus épatant, c'est que tout ce dont je viens de vous parler, ce n'est vraiment pas le cœur du bouquin. Le cœur du propos de Ken Beck porte sur un tout autre sujet, et ça porte sur un sujet qui pourrait nous être vraiment très utile à nous tous aujourd'hui. Le cœur du propos, en fait, Ken Beck, porte sur le lien social. Sur l'importance de créer des équipes soudées. Parce que pour Ken Beck, une équipe, c'est bien plus qu'un groupe d'individus qui travaillent les uns à côté des autres. Dans une équipe, on travaille vraiment ensemble. On s'entraide, on grandit au contact de ses collègues. Et puis dans une équipe, on se fait confiance. On est généralement hyper motivé d'aller travailler. On est normalement plutôt heureux au travail. Et là maintenant, pour vous, j'ai une question. Vos équipes, vous pensez qu'elles sont heureuses?
Apparemment, si c'est le cas, vous avez de la chance, parce qu'on traverse une période un peu compliquée. Entre la grande démission et ce qu'on appelle le phénomène du quiet quitting, il y a quelques soucis. Si je vous parle aujourd'hui d'XP, c'est parce que j'ai vraiment la chance d'être CTO chez Comet depuis trois ans et je m'efforce d'appliquer les préceptes de Kenbeck. Et ça marche plutôt bien. Et vous allez me dire à quoi ça ressemble une équipe XP. Je vous présente mon équipe. Alors autant vous dire tout de suite que pour Kenbeck, l'équipe c'est vraiment quelque chose de large. Ça regroupe vraiment toutes les parties prenantes autour d'un problème. Ça regroupe aussi bien les ingénieurs que le produit, les designers, ça va jusqu'au client, ça va jusqu'au business. Ce jour-là, on était quasiment au complet. Il manquait juste Nicolas qui représente chez nous le business. Et puis pour Canbeck, l'idée c'est vraiment de faire tomber les silos. De maximiser la collaboration, et puis il propose même d'installer tout ce petit monde dans la même pièce, dans le même open space.
Ce jour-là, il y avait des problèmes de RER, un peu comme aujourd'hui. On était assez nombreux à être en télétravail. De toute façon, on a une partie de l'équipe qui est en full remote. Alors installer tout le monde dans la même pièce, ce n'est pas vraiment facile. La solution que nous on a trouvée, c'est un soft qui ne paye vraiment pas de mine, qui ne fait vraiment pas sérieux, qui fait un peu gadget, mais qui est vraiment hyper pratique, qui s'appelle Gazertown. Et qui permet, en fait, l'idée, c'est que ça devient aussi facile à la maison de démarrer une conversation avec un collègue que ça ne l'est au bureau, quand on a juste à se lever de sa chaise et d'aller au desk d'à côté. Comme on travaille en mode XP, on travaille vraiment de manière collaborative. Quand on est à la maison, on ne le fait pas forcément comme tout le monde. On a généralement la caméra qui est allumée en permanence. C'est vraiment hyper efficace pour lutter contre le sentiment d'isolement.
éprouver parfois quand on travaille à la maison. Mais je ne vais pas vous le survendre. Ça ne va pas remplacer le fait de se voir pour de vrai, le fait d'échanger en présentiel, d'avoir une conversation en face à face. Et puis j'ai vraiment la chance de bosser chez Comet. Et je peux vous dire que sans trop me forcer pour faire de la pub pour ma boîte, que jamais j'aurais imaginé avoir un tel cadre de travail. Oui, c'est quand même très très beau. On est très bien accueillis. Et puis surtout, dans les lieux Comet, il y a vraiment tout ce qu'il faut pour travailler de manière collaborative. Du coup, on n'hésite pas avec mon équipe à se réunir dans un lieu comète. Et ça donne ça. On fait un peu de bruit, il y a beaucoup d'échanges, beaucoup de conversations. La communication, c'est essentiel dans une équipe XP. Et du coup, quand je recrute, je vais m'intéresser certes aux hard skills, mais aussi beaucoup aux soft skills.
Ken Beck propose de faire venir le ou la candidate une journée sur site pour échanger avec l'équipe, pour travailler avec l'équipe. Honnêtement, en France, c'est un peu compliqué. Du coup, ce qu'on fait, c'est plutôt une session de travail de deux heures sur un projet fictif avec deux ou trois membres de l'équipe. Pour l'avoir fait plusieurs fois, c'est vraiment super efficace. Et bon, alors là, je vous parle de communication. S'il n'y a pas de respect, la communication, ça ne marche pas très, très bien. Kenbeck lui propose que chaque membre de l'équipe bénéficie du même capital respect. Il faut que chaque personne dans l'équipe ait une voix qui porte autant que les autres. Il faut en gros qu'il y ait de la sécurité psychologique. Alors, ce n'est pas facile pour moi de vous dire concrètement comment ça peut s'appliquer. Ce que je peux vous dire, c'est que quand il y a des choix structurants à faire, quand il y a des gros choix techniques, je vais m'efforcer de donner la parole à tout le monde dans l'équipe et en priorité aux juniors. Je vous parle de communication, je vous parle de respect. Le troisième point qui est vraiment important, c'est le feedback.
Quand on travaille en mode XP, Du feedback, on en veut au maximum et on en veut le plus tôt possible. Et on en veut quand on écrit du code. Alors souvent dans les équipes, on travaille à base de branches, de pull requests, de code review. Oui, c'est une façon de travailler qui permet d'avoir du feedback, mais ce n'est pas vraiment la façon XP. Parce que le feedback qu'on reçoit là, on le reçoit vraiment tard. On le reçoit une fois que le boulot est fini. Quand on travaille en mode XP, le feedback, on va essayer de l'avoir le plus tôt possible, plutôt en travaillant à plusieurs devant un écran. Ça permet d'avoir une sorte de code review, mais vraiment en live. Et puis le feedback, ça vaut aussi avec le business. Kenbeck lui propose de travailler en mode itératif avec des itérations d'une semaine. Dans la première édition, il était à deux semaines, et dans la deuxième édition du livre, il s'est dit que c'était plus naturel le rythme d'une semaine. C'est ce qu'on fait chez Comet depuis trois ans. Ça marche vraiment bien. Concrètement, tous les vendredis après-midi, on a une réunion avec l'ensemble de l'équipe, business compris.
On fait le bilan de la semaine, une démo, un échange de feedback, et puis on s'accorde sur les priorités de la semaine suivante. Une semaine, ça peut paraître un peu court, parce que 5 jours, il vaut mieux ne pas perdre de temps. Il ne faut pas tomber dans le piège de faire des heures supplémentaires. Il y a un équilibre vie pro-vie perso qui est vraiment essentiel si on veut tenir sur la durée. Ken Bell propose même de garder un petit peu de mou, ce que lui il appelle du slack time. Et nous, typiquement, ça va être le lundi matin, du temps pour essayer de nouvelles choses, de nouveaux outils, de nouvelles technos. Et ça permet de trouver des opportunités pour encore mieux travailler, pour être encore plus efficace. Je vous ai parlé de ce rythme d'une semaine, il est exigeant et il y a quelque chose qui est vraiment clé pour pouvoir le tenir. C'est une quête permanente de la simplicité.
Pour moi, c'est un peu une obsession, faire en sorte que ce qu'on développe, le code et les architectures des systèmes que l'on construit, ça reste le plus simple possible, qu'on évite les chantiers technico-techniques qui n'apportent pas vraiment de valeur. Il y a un truc aussi qui est essentiel avec la simplicité, c'est que quand on a quelque chose de simple, ça peut évoluer facilement. Il y a quelque chose que je ne vous ai pas dit sur le livre, le sous-titre c'est« Embrasser le changement». En fait, il y a vraiment plein de choses que je ne vous ai pas encore dit sur XP. mais j'espère que je vous ai donné envie de le lire ou de le relire. Et puis ce que je peux vous dire, c'est que chez Comet, on est vraiment très heureux de vous accueillir aujourd'hui. d'accueillir le Tech.Rocks Summit, parce que vraiment, c'est la vocation de ce lieu, c'est la vocation des lieux que commettent d'accueillir les événements qui font vivre le lien social. Je vous remercie. Merci, merci Alexandre.
Non, ne partez pas Alexandre. Non, restez avec moi. J'arrive, vous partez. Alors que c'était vraiment impassionnant déjà, premièrement. Conseiller un livre, c'est super bien pour démarrer le matin. Moi, je garde quand même la simplicité. Je crois qu'il faut aussi faire les choses le plus simplement possible. Embrasser le changement, il n'y a quand même rien de plus ambitieux pour les années qui arrivent pour nous. Alors, vous allez vous prêter au jeu des questions-réponses, si vous en êtes d'accord. Ok, très bien. Est-ce que vous avez quelques questions par rapport à... Ah, génial! Donc, vous allez vous lever, si vous le voulez bien, décliner votre identité, votre numéro de matricule. Ce sera formidable. Et quelqu'un va venir vous apporter tout de suite un micro. En l'occurrence, je pense que ça va être moi. On va faire les choses comme à la maison. Je vais demander un petit micro derrière, s'il vous plaît. Merci beaucoup. Voilà. Regardez, on sait tout faire chez Tech.Rocks Summit. Merci Nicolas, c'est très gentil. Alors, c'est pour monsieur là-bas. Ouais, mais bon, moi je suis petite.
Bonjour, Alexis Berges, directeur de l'ingénierie en IA chez Préligence. J'ai une question concernant l'organisation que vous décriviez. Vous parliez du fait qu'il y avait une fois par semaine toute l'équipe, y compris le business, qui se retrouvait. J'ai l'impression qu'implicitement, il y a quand même une notion de taille, qui est que si on est dans une boîte où cette partie-là de la boîte représente 200 personnes, ça va... peut-être poser des problèmes et je voudrais savoir ce que vous en pensez, à quel moment il y a peut-être des questions, est-ce qu'on garde tout le monde tout le temps? Elle est pour vous la question, pas pour moi. Bien sûr. Merci pour cette question. Alors effectivement, on se pose souvent la question de la scalabilité d'XP. En fait, une équipe XP, ce n'est pas scalable, mais en fait, n'importe quelle équipe n'est pas scalable parce qu'une équipe, quelle que soit la méthode, pour qu'elle fonctionne, il faut de la confiance, il faut que les gens se connaissent. Il y a tout un chapitre du livre là-dessus. Le...
Généralement, ce qu'on va essayer de faire, c'est de faire plein de petites équipes. Ce qui est important, c'est de trouver un interlocuteur côté business qui est vraiment impliqué. Mais je pense que ça, pour le coup, c'est vraiment un facteur de succès, quelle que soit la méthode. Si on n'a pas un sponsor, quelqu'un qui est vraiment décideur côté business et qui est vraiment impliqué dans le projet, c'est assez difficile, je pense, de réussir. Réponse acceptée? Génial. Est-ce qu'il y a une autre question dans la salle? Non? Ah, deux? Oh là là, formidable. Donc pareil, je vais vous demander de vous lever, de décliner gentiment votre identité. Oui, bonjour, Nicolas de chez Stoic. J'ai une petite question sur la partie meeting entre les techs où vous dites que vous donnez la parole aux juniors au début. Pourquoi? Qu'est-ce que ça crée? Et comment on gère les nouveaux arrivants par rapport aux autres? Je ne suis pas sûr d'avoir bien compris la question à propos des juniors.
Vous donnez la parole aux juniors. Oui, oui, oui. Alors, pourquoi je donne la parole aux juniors ? Parce que quand on est senior, on a tendance à avoir des habitudes, on a tendance à reproduire des solutions qu'on a pu mettre en place par le passé, à calquer ce qu'on sait faire. Le fait d'avoir des juniors, ça permet de se remettre en cause. Il y a souvent des questions qui peuvent paraître comme ça naïves, mais en fait qui permettent de se remettre en cause et de remettre en question ce qui est déjà établi et peut-être de nous aider à trouver des solutions plus simples. L'intergénérationnel, fondamental pour trouver les solutions ensemble. Merci beaucoup. Merci. Nicolas, ça vous va comme réponse? Parfait. Je crois qu'on avait une dernière question. Voilà, j'ai dit dernière, peut-être une autre ensuite. À qui avons-nous? Bonjour, Henri Pelletier, directeur technique et produit chez TINBU. Je pense qu'on est beaucoup ici à connaître XP et à être convaincus qu'il y a beaucoup de choses super intéressantes dedans. Et pourtant, dans toutes les organisations, ce n'est pas ça qui vient.
Est-ce qu'on dit faisons du Scrum? Et donc, pourquoi on n'a pas réussi à faire de XP? Est-ce que c'est juste le nom? La méthode principale par rapport à d'autres, alors qu'on le sait tous, ça marche beaucoup mieux. Et même quasiment les pratiques qui sont dedans sont indispensables. Si on veut que ça fonctionne. Comme dit Ken Beck, qui n'a pas envie d'être un master, un scrum master? Je pense que c'est surtout une histoire de marketing. Il n'y a pas de certification, il n'y a pas de business, il n'y a pas de consulti. associé à XP. Et voilà, je pense que c'est la raison essentielle du fait que ce soit moins répandu. J'ai espoir, c'est pour ça que je vous en parle aujourd'hui, que XP va être quelque chose qui va être plus répandu. Et qu'on va commencer un petit peu plus à l'adopter, parce que ça fait quand même plus de 20 ans. Et il y a des mauvais réflexes qui reviennent. En même temps, si on est tous convaincus, peut-être qu'il y a quelque chose à faire avec la communauté Tech.Rocks, pourquoi pas?
Exactement. On va essayer de gonfler le marketing d'XP, non? Ça pourrait être une première piste pour ce matin. Est-ce qu'il y a une autre question dans la salle? Non. Ah, une dernière. Pour monsieur. T-shirt, enfin, pull, brique. Très jolie pull, d'ailleurs. Franchement, je pensais que j'étais la mieux sapée, mais ce n'est pas le vrai. Merci. Julien Tabé, architecte applicatif chez Bayard. Ma question était par rapport au ratio du pire programming dans la méthode XP par rapport au reste du travail de la semaine. Vous disiez qu'il y avait des itérations d'une semaine, ce qui fait que c'est assez court, ceci dit, mais le temps que passent les gens à faire du pire programming ensemble sur le même écran, comme vous avez montré tout à l'heure, ça représente quoi à peu près sur une semaine? Ça représente la majorité du temps. C'est peut-être contre-intuitif le fait de se dire que quand on est tout seul, on va plus vite. C'est peut-être le cas à court terme. Je peux vous assurer que sur le long terme, le fait de travailler ensemble, ça permet vraiment d'avoir une connaissance qui est vraiment diffusée au sein de toute l'équipe.
Et puis surtout, je n'en ai pas parlé tout à l'heure, mais ça permet aussi d'avoir ce qu'on appelle le collective ownership. Le fait que n'importe qui peut intervenir sur n'importe quelle portion du code. Et puis, j'ai aussi oublié de le dire, mais souvent dans les équipes, on a tendance à séparer des profils un peu spécialisés. D'un côté, les développeurs front, d'un côté, les développeurs back. On se dit, tiens, on va créer une sorte de mini silo. Et puis comme ça, les front vont pouvoir tracer. Et puis les back, ils vont aussi pouvoir dépoter. Mais en fait, si on met deux profils hyper complémentaires ensemble, ils vont pouvoir développer une fonctionnalité de A à Z de manière hyper efficace, sans avoir ensuite des coûts de coordination. Et puis, je ne veux pas se mettre sur les conflits qu'il peut y avoir dans les équipes, les guerres d'égo et toutes ces choses-là qu'on connaît bien. Tout seul, on va plus vite. Ensemble, on va plus loin. Voilà, ça c'est Maître Gims qui le disait dans une de ses chansons aussi.
On a les références qu'on a. Bah voilà, mais n'empêche qu'il nous inspire aussi pas mal, Maître Gims, de temps en temps. Est-ce qu'il y a une autre question dans la salle, une dernière, où on laisse Alexandre retourner faire le marketing d'XP pour le monde entier? Non? Bon bah parfait, merci infiniment. Merci Alexandre, je rappelle que vous êtes CTO de Comet. A bientôt.
