Comment organisons-nous la veille technologique collective dans l'équipe Web

Cet article se présente comme un retour d'expériences concernant l'organisation de la veille technologique collective au sein de l'équipe Web de Wanadev. Laissez-moi vous présenter le contexte et nos problématiques.

Pour démarrer, rappels sur l'histoire de notre équipe

Je m'appelle Baptiste, je suis Technical Lead chez Wanadev depuis plus de 5 ans. Lorsque je suis arrivé dans l'équipe, je ressentais Wanadev, dans le discours et l'attitude générale, comme une entreprise technique composée de techniciens passionnés. Cela l'a toujours été, et le restera : notre Leitmotiv n'a pas changé : faire de la qualité tout en prenant du plaisir.

Arrivé comme développeur junior, la petite équipe n'a eu de cesse d'apprendre toujours et encore, avec objectif de toujours se perfectionner sur PHP, Symfony, ou améliorer nos process et nos méthologies… À ce moment là, il était particulièrement facile de faire bouger les choses, rien n'était clairement défini et la petite taille de l'équipe de l'époque rendait flexibles les changements de procédure.

^ Le soir j'allais à un meetup. Le lendemain on en discutait et on appliquait presque dans la foulée.

Rapidement l'équipe s'est renforcée, il fallait former les nouveaux arrivés, expliquer nos pratiques et nos méthodes. Notre technique progressait mais il était plus difficile de partager nos pratiques, compte tenu de l'agrandissement des équipes.

L'agilité, c'est aussi savoir évoluer nous même. Comme cela est dans notre ADN chez Wanadev, nous avons essayé de nous adapter.

Nous mettons alors en place un point/format qui répond aux problématiques en cours, lui-même deviendra par la suite caduc lorsque de nouvelles problématiques donneront lieu à un nouveau format. Bref, de l'évolution permanente, imposant son lot d'amélioration des process, de développement, de veille.

Comme de nombreuses entreprises, nous avons cherché dans les méthodes Agile et nous avons mis en place ce que nous appelons le "stand-up" du lundi matin.

Lors de cet événement hebdomadaire, chaque membre de l'équipe Web échange avec les autres pour donner les informations clés sur l'avancement et les problématiques de ses projets en cours.

Ce même point était donc le moment pour nous de recueillir les différents sujets techniques qui pourraient faire l'objet d'une présentation plus poussée ultérieurement.

^ Les sujets pouvaient être proposés (ou demandés). « Je connais quelque chose dont je veux vous parler » ou « J'aimerais qu'on me présente Docker ».

Ce format a bien fonctionné durant un certains temps. Mais comme chaque chose évolue... il fallait trouver de nouvelles méthodes de veilles collectives pour rester en phase avec notre équipe et nos travaux.

Ces types d'« organisation » sont, entre autres, basés sur l'investissement personnel de chacun : vouloir présenter, prendre le temps de former, de préparer des documents et ressources, tout ça prend du temps et de l'énergie.

L'équipe continua à grandir, de nouvelles personnes vinrent compléter les équipes. Et de fait, une augmentation des effectifs a pour effet de changer relativement (mais logiquement) des process plus forcément adaptés : les développeurs séniors chargés de former, accueillir, accompagner peuvent perdre une part de liberté, ou en tout cas une partie de celle d'aménager de leur énergie/temps disponible au partage de connaissances.

Ainsi, nous avons constaté, comme une corrélation, un essoufflement des présentations techniques internes et des articles publiés sur le blog de l'équipe. C'était donc un problème !

@ Les sujets sollicités étaient de moins en moins nombreux. Les gens demandaient de moins en moins. Le temps est une ressource précieuse et nous n'en avions pas forcément assez pour continuer nos efforts quand d'autres tâches, plus court-termistes nous semblaient plus importantes. Et personne ne pouvait être blâmé pour ça.

On peut voir que la majorité des articles postés proviennent d'un nombre limité d'auteurs.

Sur ces deux graphiques on peut voir que de nombreux articles ont été produits en 2016. Entre 2016 et 2018, nos effectifs ont plus que doublés tandis que le nombre d'articles publiés par an a été divisé par 3 (53 en 2016 contre 17 avec celui-ci en 2018).

@ Pour vulgariser un peu la situation, nous constations simplement que chacun réalisait sa propre veille technique pour lui, sans plus n'avoir l'environnement propice au partage. Quel dommage !

Secouer l'écosystème de veille et se remobiliser collectivement : les solutions envisagées

Une réflexion a donc été engagée pour trouver un nouveau moyen de transmettre de l'information au sein de notre équipe, harmoniser nos conventions et faire progresser toute l'équipe au même rythme plutôt que de rester sur une veille personnelle. Car évidemment, nous avons toujours une volonté intacte de réaliser des projets de qualité tout en proposant des pratiques dans l'air du temps.

La réflexion de proposer de nouveaux formats de veille collective a été poursuivie sur plusieurs mois durant lesquels nous essayions dans un premier temps de savoir comment s'affairaient les autres, les gros, les références. Facile et prédictible : les Google et compagnies devinrent alors rapidement des références.

^ Sur la toile, on peut trouver des informations comme quoi Google allouerait jusqu'à 20% du temps de travail en veille et projet.

Mais tout le monde n'est évidemment pas Google. Il n'est pas toujours évident (et ce pour plusieurs raisons) de fixer et de réserver une plage immuable dédiée à la veille : deadline, aléas, formation... la vie en entreprise quoi !

L'idée d'allouer X % de notre temps à faire de la veille a longtemps été celle implicitement effectuée. Sans avoir le temps de partager et de mutualiser les recherches. Notre problème : arriver à en parler et faire passer des informations de qualité de manière homogène à toute l'équipe.

La solution retenue pour un nouveau format de veille au sein de notre équipe désormais plus large

Étape 1

Chaque semaine - le lundi - j'organise des entretiens. Ce moment est dédié à la distribution de nouveaux sujets à une personne libre qui souhaite participer. Ce jour est également le moment pour moi de faire un point d'avancement avec les personnes ayant déjà un sujet en cours (voir étape 3).

@ On distribue un sujet maximum par semaine. Cela permet d'éviter les lancements en fanfares la semaine 1 et les disettes la semaine 2.

Le choix du sujet

Le choix du sujet donne nécessairement lieu à une concertation, autrement il est impossible d'espérer avoir des résultats. Le sujet est généralement proposé par moi-même (selon les affinités front/back/ops ou autres) mais le sujet peut également être amené par une personne de l'équipe ou en fonction des besoins à venir. Ces sujets se rapprochent inévitablement des campagnes de R&D que nous menons.

^ Il est important de rester à l'écoute car notre objectif est de produire une veille de qualité. Le porteur du sujet est donc le seul à pouvoir valoriser le sujet.

Les sujets distribués touchent à de nombreux domaines :

• Nouvelle librairie/framework
• Nouveau standard
• Convention/méthodologie/bonnes pratiques
• La gestion de projet, etc...

^ Il n'est pas exclu de travailler sur un sujet plus éloigné de notre activité quotidienne ! Cela valorisera notre culture. Ca ne fait jamais de mal, et puis... la sérendipité est toujours agréable.

Étape 2 : mise en place des objectifs

Les sujets n'ont pas toujours les mêmes objectifs. Selon le travail à fournir, on produira différents documents.

• Présentation orale à l'équipe
• Document interne
• Article à destination du blog

Pour les plus gros sujets, ces trois objectifs pourraient être atteints.

Le sujet sélectionné, aucune deadline de livraison finale n'est programmée. Cela doit nous permettre de pouvoir ajuster la cadence en tenant compte de la charge de travail et des contraintes extra-professionnelles.

Étape 3 : mise en place de points réguliers

Comme dit dans l'étape 2, nous ne définissons pas de date de livraison finale. Cependant nous définissons des objectifs d'avancement d'un rendez-vous à l'autre.

Exemple concrêt :

• Le sujet sera, pour prendre quelque chose en cours d'étude : "Définir un convention pour nos feuilles de styles (CSS)". Il s'agit d'un sujet vaste, de nombreux points seront nécessaires. Lors de ce premier point, nous définissons un axe de recherche pour la prochaine étape, comme "Étudier les différentes méthodes connues". Le porteur du sujet m'indique qu'en tenant compte de sa charge de travail et des recherches à entreprise, il aura besoin de 2 semaines, 1 mois ou plus.
• Puis, lors du point suivant, le travail intermédiaire est simplement présenté ce qui permet de tout de suite orienter la suite des recherches et éventuellement de corriger le tir. On recommence cette étape jusqu'à ce que le sujet est traité suffisamment en profondeur et que les documents finaux produits sont suffisants pour être partagés.

Étape 4 : présentation du travail à l'équipe

• Présentation orale à toute l'équipe
• Mise à disposition du document interne. Généralement il s'agit d'un document relatif à une méthode ou une convention déterminée que nous souhaitons généraliser sur tous nos projets.
• Mise en ligne de l'article sur le blog.

Veille technique en équipe et règles d'or

• Cela pourrait faire penser à de la rétention d'information mais les sujets sont traités avec un maximum de discrétion. Les sujets distribués ne sont connus que par le porteur du sujet et le référent technique. L'objectif recherché est d'impliquer le porteur en le laissant se faire sa propre opinion et en maximisant l'effet de "surprise". Par expérience, cela est nécessaire pour capter toute l'attention.
• Le délai entre deux points ne doit ni être trop court (minimum 2 semaines) ni trop long (maximum 2 mois). Cela permet de s'organiser et de construire le travail de manière régulière en évitant les "rush" ou les longues périodes de relâchement.

Retour d'expérience et conclusion

Aujourd'hui, cela fait 7 mois que nous appliquons ce format et il me semble répondre aux problématiques que nous avions. Il permet de valoriser et de partager le savoir mais également de challenger notre équipe.

L'équipe a particulièrement apprécié ce format bien qu'il ne réponde pas clairement à une problématique persistante : l'allocation de temps.

Aujourd'hui, aucun temps n'est spécifiquement alloué. Nous acceptons qu'une demi-journée par semaine puisse être prise bien qu'il nous soit impossible de l'assurer. Il convient donc au porteur du sujet de s'organiser dans son travail et de tenir compte des contraintes projets/clients lorsque la date du prochain point est émise.

^ Aujourd'hui cette solution n'est pas suffisante et nous tentons de faire évoluer à nouveau ce process pour maximiser le temps passé.

Quelques chiffres sur notre veille collective

Entre mai et novembre (7 mois) :

• 10 sujets majeurs ont été distribués ;
• 3 ont été conclus (3 présentations, 2 documents internes, 1 article de blog à venir) ;
• 1 sujet a été abandonné car mal ciblé

@gianninapolipro ouvre l'après midi avec un atelier sur les méthodologies CSS lors de travaux en équipe.

— Wanadev 🐙 (@Agence_WanaDev) 22 novembre 2018

Organisation des présentations

Les 3 premiers sujets conclus, il était pour nous le moment des présentations ; pour mobiliser l'attention autour de ces sujets et permettre un débat, nous avons loué une salle en dehors des locaux lors d'une après-midi, histoire de parler tech sans être pour autant presser de retourner à son poste.