Pourquoi le caddying

Le caddying est une nouvelle étape dans notre mise en place de méthodes de développement agiles (SCRUM principalement), et c'est une tentative de privilégier "les individus et leurs interactions plutôt que les processus et les outils" (cf. le manifeste agile). Notre besoin était de trouver un moyen simple d'alimenter une dynamique d'amélioration continue. Au début nous nous sommes beaucoup appuyés sur une démarche très orientée processus. Toutefois il me semble que sans une réelle dynamique d'amélioration continue, une pratique "orientée processus" de SCRUM comporte un fort risque de délivrer régulièrement et de manière prédictible des produits médiocres. La qualité des produits et la performance des équipes ne viennent pas automatiquement ni magiquement en suivant plus ou moins à la lettre un processus. Au mieux, la qualité augmente un peu parce que vous accordez plus d'attention aux tests, tandis que certains gaspillages sont supprimés étant donné que SCRUM est naturellement lean, mais vous atteignez vite un plateau.

L'idée du caddying est venue de discussions sur ces thèmes avec François Beauregard qui nous avait expliqué ce concept de caddying mis en place dans Pyxis. Nous avons ensuite adapté la démarche à notre contexte, essentiellement en donnant un axe assez technique au caddying pour l'instant.

Notre caddying a certains points communs avec le mentorat, terme qui selon Wikipedia "désigne une relation interpersonnelle de soutien, d'échanges et d'apprentissage, dans laquelle une personne d'expérience, le mentor, investit sa sagesse acquise et son expertise afin de favoriser le développement d'une autre personne, le mentoré, qui a des compétences à acquérir et des objectifs professionnels à atteindre". Mais il nous paraît plus sain d'éviter des termes chargés de sens vagues ou d'a priori comme coach ou mentor, qui requièrent de laborieuses clarifications (voir Managing vs. Coaching vs. Mentoring).

Aussi nous parlons simplement de caddy et de joueur (en référence à ces deux "rôles" dans le golf). Attention, le caddy n'est pas un simple porteur de clubs, c'est un joueur expérimenté qui connaît bien le parcours, et qui est indispensable même aux meilleurs joueurs mondiaux.

Ce billet décrit concrètement comment se passe le caddying dans notre contexte (édition de logiciels scientifiques), en présentant les thèmes sur lesquels nous travaillons, la mise en place concrète, les avantages et inconvénients identifiés après un peu plus de six mois de pratique.

[Suite:]

Nos thèmes

Les thèmes "émergent" en fonction de plusieurs facteurs :

• besoins stratégiques de l'entreprise. Par exemple nous souhaitons améliorer la performance de nos applications scientifiques, et pour cela il serait utile d'avoir des développeurs mieux formés sur le développement multi-thread.
• envie d'un caddy de partager ses connaissances (par exemple ergonomie, ou encore GTD) ou d'approfondir un sujet qui le passionne (par exemple la programmation fonctionnelle)
• besoin de formation identifiés par certains joueurs (par exemple augmenter leur connaissances métier, ou mieux maîtriser leur ordinateur)

Nous avons actuellement les thèmes suivants :

• bureautique : cela permet à un joueur qui n'est pas informaticien de bénéficier des connaissances d'un développeur, pour mieux comprendre des aspects de l'informatique qui l'intéressent. Par nature le contenu est très varié, et complètement déterminé par les questions du joueur. Par exemple la dernière séance de 2H a été consacrée à maintenir le PC bien à jour avec Secunia Personal Software Inspector (PSI), sauvegarder des partitions avec Acronis True Image ou DriveImage XML, et partitionner un disque avec GParted (et pour cela il a fallu explorer la notion de partition).
• ergonomie : ici les joueurs apprennent des notions théoriques, puis passent nos logiciels au crible de critères d'ergonomie et réalisent des tests d'utilisabilité. Cela a des conséquences assez rapidement puisque leurs conclusions vont être implémentées dans les prochaines versions. D'autre part notre processus de développement sera modifié pour prendre en compte leur expérience et travaux, et cela va contribuer à augmenter la maturité de nos équipes sur la question, et augmenter la satisfaction des clients.
• tests agiles : un joueur étudie à son rythme le livre Agile Testing, a identifié les blogs des principaux gourous du test agile, et publie régulièrement des billets internes sur les aspects pertinents par rapport à nos pratiques (les quadrants du test agile, les tests exploratoires, les spécifications exécutables). Cette activité qui n'existait pas du tout auparavant contribue à augmenter notre maturité sur le test en général. Un autre joueur travaille sur la compréhension et l'implémentation d'un "presenter" dans une application réaliste, afin de nous faire progresser sur la question difficile des tests d'interfaces graphiques.
• programmation multi-thread : avec un caddy expérimenté, plusieurs joueurs travaillent en randori sur divers problèmes, comparent des solutions (notamment leurs performances - ça tombe bien, c'est un de nos thèmes stratégiques), et approfondissent de nombreuses notions (verrous, opérations atomiques, framework QtConcurrent, MapReduce). Pour l'instant tout cela est en C++, pour des développeurs C++, mais il serait intéressant plus tard d'impliquer d'autres développeurs qui eux travaillent en C#.
• programmation fonctionnelle (F#, Erlang)  :  Ici joueur et caddy apprennent ensemble les concepts de la programmation fonctionnelle. Ce thème est intéressant par ses applications à moyen terme : maîtriser la programmation fonctionnelle est certainement un bon moyen d'apprendre à écrire du code plus propre et plus facilement parallélisable (ça tombe bien, cela peut améliorer les performances). De plus, la programmation fonctionnelle s'adapte bien aux algorithmes "scientifiques".
• GTD :  avec un caddy qui a appris tout seul la méthode, les joueurs apprennent à mieux s'organiser par la méthode Getting Things Done, de David Allen. Ici l'organisation est particulière, avec une longue séance initiale pour mettre en place la méthode (des m3 de papier inutile sont généralement éliminés à ce stade), et de courtes séances régulières pour ancrer la méthode.
• connaissances métier : plusieurs développeurs ont exprimé le besoin d'être mieux formés sur l'utilisation qui est faite des logiciels qu'ils développement, et donc ils travaillent régulièrement avec une de nos spécialistes "métier". Ils ont choisi avec leur caddy de devenir capables de faire passer tout seuls les tests d'acceptance de leur logiciels sur nos instruments (c'est une bonne idée car ces tests représentent un goulot d'étranglement dans la livraison de logiciels par manque de personnes capables de les faire passer).
• agilité : Ici un joueur Scrummaster échange régulièrement avec son caddy sur la manière dont il pratique Scrum, les difficultés qu'il rencontre, les billets ou articles récents.
• lean : ce thème a permis notamment d'aider nos "product owners" à mieux gérer leur backlog et à mieux écrire leurs histoires utilisateur. Il a permis également de réorganiser notre laboratoire avec la méthode des 5S.
• lecture rapide : ici un lecteur moyen cherche à doubler sa vitesse de lecture, grâce à deux séances de travail par semaine, basées sur l'étude de livres comme Méthode de Lecture rapide et 10 Days to Faster Reading.

Nous avons également des caddies volontaires pour un thème "troubleshooting" et pour un thème "communication et facilitation" mais aucun joueur ne s'est proposé pour l'instant. Cela illustre le fait que le caddying ne marche que quand il y a rencontre entre un besoin et une offre de services !

Comment ça marche en pratique

Fonctionnement

Il n'y a pas de processus très formalisé pour décider des thèmes - en pratique il suffit que deux personnes se désignent comme caddy et joueur pour que le travail sur un nouveau thème puisse démarrer ! La principale contrainte est de rester dans des limites de temps raisonnable (20% de son temps par semaine pour un caddy, et de l'ordre de 2H par semaine pour un joueur).

Le temps ? C'est le mot-clé ! Souvent on me demande comment cette initiative (et d'autres, comme participer régulièrement aux coding dojos du CARA, ou encore notre journée "labo" régulière) est possible, comment on nous laisse faire tout cela au lieu de nous faire travailler à fond sur les projets en cours. Eh bien pour l'instant personne n'a démontré que ces initiatives ralentissaient la sortie d'un logiciel. J'ai une hypothèse là-dessus : comme les cartes de valeur (value stream mapping) dans le cas du développement logiciel montrent des ratios d'efficacité assez faibles, il est possible que ces initiatives consomment bien plus de temps dans les périodes d'inefficacité que dans les périodes d'efficacité. En quelque sorte, nous utiliserions le temps autrefois gaspillé pour nous améliorer ! Mais c'est une hypothèse qui reste à démontrer.

Le fonctionnement est très flexible, et laissé à l'appréciation du caddy et de ses joueurs. L'idée de départ était surtout une relation en tête-à-tête, mais en pratique plusieurs caddies travaillent avec un groupe de joueurs en même temps, surtout quand les caddies sont très demandés. Certains joueurs indiquent tout de même qu'ils auraient préféré un accompagnement individuel (afin de ne pas perdre du temps quand certains contenus ne les intéressent pas), mais nous n'avons pas toujours assez de temps de caddy (certains caddies ont d'autres rôles comme ScrumMaster, ou encore travaillent à temps partiel).

Quand il n'y a qu'un seul joueur, nous avons comme principe de laisser le joueur poser les réunions avec son caddy. Ainsi le joueur est complètement responsable du planning, et peut déterminer le rythme qui lui convient - charge au caddy de s'adapter. Quand le joueur tarde à poser les réunions, c'est peut-être signe que la relation s'essouffle et qu'il est peut-être temps de conclure.

La durée de l'accompagnement est donc libre également, et va de quelques semaines à plusieurs mois, en fonction de la densité du contenu exploré, et de l'énergie que caddy et joueurs veulent consacrer au thème.

Ce travail est assez exigeant pour le caddy qui doit souvent approfondir ses propres connaissances, et parfois préparer du matériel pédagogique. J'espère donc qu'il y aura plusieurs générations successives de joueurs pour un caddy donné, afin de plus rentabiliser le temps investi par le caddy. Cela paraît certain pour certains de nos thèmes (GTD, connaissances métier), pour d'autres thèmes c'est moins évident.

Nous avons également identifié un rôle de "meta-caddy", que j'ai décrit dans cet autre billet. Mais ce n'est pas un rôle très directif actuellement, car il nous semble plus important de laisser vivre le système et d'expérimenter, plutôt que de chercher à le contrôler.

Evaluation

Nous demandons aux joueurs de s'auto-évaluer en début et en fin de parcours (voire aussi en cours de route si c'est utile), selon différents axes qu'ils identifient avec leur caddy. Ci-dessous je montre certaines de ces auto-évaluations.

Voici une première illustration dans le thème GTD (c'est le caddy qui s'est lui même auto-évalué pour identifier les axes intéressants pour ses joueurs) :

Voici l'auto-évaluation d'un joueur dans le thème bureautique :

 

et pour un autre joueur dans le thème ergonomie :

Dans tous les cas il y a de nettes progressions sur certains axes, et d'autres axes avec peu de progrès, généralement parce qu'ils n'ont pas été suffisamment explorés pendant le caddying, souvent par manque de temps. Ces auto-évaluations permettent au joueur et au caddy de corriger le tir si besoin.

Avantages

Par rapport à une formation classique, cette formule présente l'avantage d'être "à la carte", sous forme de cours quasiment particuliers très adaptés à nos besoins, et peu couteux. Quand nous avons organisé des formations auparavant, elles sont souvent été jugées trop théoriques, avec trop de participants, ou pas assez reliées à notre travail.

Dans le même ordre d'idée, l'avantage du caddying est que tout ce que l'on apprend est immédiatement utilisable, et qu'il est possible d'avoir un suivi qui contribue à ancrer les nouvelles connaissances. En effet, même quand vous avez terminé votre travail avec un caddy, ce dernier reste disponible pour assurer un suivi à une fréquence différente, ou encore pour vous aider ponctuellement, même dans six mois.

Le caddying évite également les relativement longues interruptions que peuvent constituer les formations classiques, puisque le joueur ou le caddy ne sont indisponibles pour leurs équipes que peu de temps chaque semaine.

Le caddying ouvre aussi un espace qui n'existait pas auparavant pour expérimenter, faire des erreurs, réaliser des prototypes.

En plus de cet espace, le caddying permet d'acquérir un certain rythme de travail ou d'étude. En effet il est facile de s'intéresser à un nouveau sujet, mais difficile de s'imposer une discipline pour l'étudier suffisamment longtemps. Justement grâce aux réunions régulières avec une autre personne, le caddying contribue à plus de discipline. Cette discipline peut même être une raison suffisante pour démarrer un travail de caddying avec une autre personne, qui n'a pas nécessairement besoin d'être beaucoup plus experte que vous dans le domaine choisi - sa contribution sera surtout d'aider à maintenir la régularité de travail sur le sujet.

C'est aussi un nouvel espace pour partager des connaissances, réduire les effets silos entre projets ou équipes, mieux connaître ses collègues, faire de la veille technologique. Et parfois il encourage à tout simplement à aider ses collègues : ainsi des formes de "micro-caddying" apparaissent maintenant spontanément. Quand une personne demande à un collègue de l'aider une ou deux heures, le terme de caddying est maintenant employé !

Enfin le caddying offre une possibilité de meilleure reconnaissance à ceux qui sont intéressés par une carrière technique, à condition qu'ils puissent faire preuve de suffisamment de pédagogie.

Inconvénients, difficultés

Le principal inconvénient est que le caddying constitue une nouvelle source possible d'interruption pour une équipe, qui peut se trouver en attente de quelque chose d'un joueur ou d'un caddy. Même s'il s'agit d'interruptions courtes comme je le signalais plus haut, ce sont des interruptions fréquentes, qui s'ajoutent à d'autres sources : réunions, RTT, temps partiel. Quand cela est possible, il faut essayer d'organiser les rencontres joueur-caddy en dehors des plages horaires où toute l'équipe travaille ensemble ; par exemple le créneau 8h-9h est assez adapté dans certains cas.

Un autre inconvénient est le risque de fonctionner en "circuit fermé" : d'une part il n'y a pas beaucoup d'apport ou d'échange extérieur, comme cela peut être le cas quand vous suivez une formation inter-entreprise ; d'autre part, les joueurs les plus convaincus sont souvent caddies dans d'autres thèmes, ce qui peut finir par limiter l'arrivée de nouveaux joueurs.

En fait plutôt que de réels inconvénients,  le caddying présente surtout certaines difficultés ou challenges. Par exemple :

• il est difficile d'adapter les besoins des joueurs et les offres de services. Nous ne sommes pas forcément suffisamment compétents ou disponibles sur tous les thèmes souhaités. Ou encore les joueurs potentiels ne sont pas forcément intéressés par tous les services que des caddies aimeraient proposer.
• les caddies potentiels ne sont pas forcément très bons en communication ou en pédagogie. Ainsi ils peuvent avoir du mal à faire une bonne "publicité" pour leurs thèmes, à simplement donner envie à des joueurs de s'inscrire.
• il est difficile de bien communiquer sur les services proposés par les caddies (en général il n'y a pas de document type support de formation que l'on peut consulter à l'avance). Ainsi il peut être difficile de toucher des joueurs potentiels qui ne voient pas bien ce qui est proposé. Dans le même ordre d'idée, certains joueurs n'aiment pas trop le fait que le programme d'étude ne soit pas fixé à l'avance.
• il faudra trouver le moyen de faire perdurer cette démarche de caddying, afin d'éviter que le succès initial ne soit qu'un feu de paille. Pour le moment nous sommes dans une phase exploratoire, et le caddying fonctionne sur la base du volontariat de tous et l'exemple donné par les managers (plusieurs se sont inscrits comme joueurs). Est-ce que dans le futur le volontariat pur suffira, ou bien il faudra mettre au point des incitations ou des obligations ? 

Enfin le caddying n'a pas vocation à résoudre tous les problèmes. Il est très adapté pour permettre à 2 ou 3 personnes d'acquérir de nouvelles compétences ou connaissances sur une durée de 3-6 mois au minimum, mais il n'est sans doute pas le meilleur moyen pour des  groupes plus importants, ou pour "monter en compétences" très rapidement. C'est pourquoi le caddying ne vise pas particulièrement à remplacer des formations classiques, à l'extérieur de l'entreprise.

Conclusion

J'ai donc présenté notre implémentation concrète d'un système particulier de mentorat, que nous appelons caddying. De tels systèmes ne sont pas nouveaux, car de nombreuses entreprises en ont déjà mis en place. Toutefois les systèmes existants semblent souvent viser uniquement les managers ou leaders, afin de faciliter ou accélérer leur carrière. Ainsi il est possible que notre particularité soit d'avoir mis en place quelque chose qui soit applicable à tous les employés, indépendamment de leur position hiérarchique. Dans ce cas ce serait une bonne application du manifeste agile que je citais en introduction !

 

Merci aux caddies qui ont pris le temps de relire et corriger ce billet, ainsi qu'à Laurent Tardif pour un échange sur ce thème.