Il y a plus d’un an que je n’ai pas pris le temps d’écrire sur ce blog. La dernière fois, je rédigeais un article sur Angular et l’implémentation d’un pattern Annuler / Rétablir. Quelques semaines plus tard, je quittais PMSIpilot à destination de RVIP pour changer d’air et d’horizon.

Beaucoup de choses ont changé depuis. L’univers du développement Web a évidemment continué sa course en avant. Nouveaux frameworks, nouveaux paradigmes, nouvelles tendances. Il y a un an, on suivait encore les propositions de specs pour Angular 2 sur Google docs, on entendait à peine parler de reactive programming ou de Typescript, ES2015 s’appelait encore ES6 et personne ne pensait à sérieusement mettre Docker en production.

Je me motive aujourd’hui pour rédiger un article un peu différent de ceux que j’écris habituellement sur ce blog puisque je ne vais pas parler de technique mais plutôt d’un retour d’expérience que nous avons mené au sein de nos équipes de développement chez RVIP.

Un poste typique de développeur

Je lisais ce matin-même un article intitulé, les développeurs sont devenus des cols bleus. Ci-dessous, un extrait qui illustre bien le propos de l’auteur quant à la vision du poste de développeur dans beaucoup d’entreprises :

Les développeurs sont souvent vus par leurs collègues et leur hiérarchie comme des ouvriers, des cols bleus. Leur tâche consistant à construire un outil qui servira le business mais qui ne constitue en soi aucune valeur. On me l’a d’ailleurs déjà dit en face: “en fait, ton boulot c’est de fabriquer nos outils”, comme si je ne participais pas à la création de valeur dans l’entreprise, que la seule valeur était produite par ceux qui utilisent l’outil pour faire du chiffre… Et vu sous cet angle, la technique n’est effectivement qu’un coût et rien d’autre pour l’entreprise. Coût qu’il convient de mesurer, de réduire et d’optimiser au mieux.

Je nuancerai tout de même le propos. J’ai de plus en plus la sensation qu’on avance dans le bon sens, que les entreprises hésitent moins à recruter des développeurs talentueux et passionnés plutôt que le premier venu dont le CV contient, au hasard d’une ligne, le nom du Framework utilisé en interne, ayant bien compris que tirer les salaires vers le bas n’est pas toujours rentable quand un business est fortement lié à la technique.

Dans tous les cas, il est vrai qu’on demande en général à un développeur de répondre aux besoins exprimés directement ou indirectement par un client (le PO par exemple), pas grand chose de plus.

Exemple d’une annonce de recrutement d’un développeur piochée au hasard (ici, au hasard = la première) sur RemixJobs :

Vos principales missions porteront sur :

• L’analyse et la conception des nouvelles fonctionnalités définies par le Product Owner
• Le développement de ces fonctionnalités
• La recette et le suivi de mise en œuvre
• La maintenance et la formation des équipes internes
• …

Quand une entreprise recherche un développeur plus expérimenté, elle rajoute souvent à sa description de poste des mots clés tels que “Lead Developer”, “Référent Technique” ou encore “Architecte”. Mais rarement des mots clés type “Créativité”, “Liberté” ou “Recherche”. Ou alors, parfois, simplement pour décorer.

La créativité, pourquoi faire ?

Je suis un fervent défenseur des méthodologies agiles et notamment de SCRUM. Je suis bien sûr familier avec les concepts d’équipe, les rôles distincts de Product Owner, Développeur et Scrum Master et je ne les remet absolument pas en question.

Au sein de la méthode SCRUM, le développeur a un rôle crucial dans la réussite du projet et du produit sur lequel l’équipe travaille et il est fortement impliqué dans les différents processus de décision qui concernent ce projet / produit.

En revanche, je trouve que ces méthodes laissent en général trop peu de place aux “à-côté”.

L’équipe se concentre par itérations successives sur son projet et n’a pas souvent le temps de souffler. Les puristes de la méthode SCRUM sont d’ailleurs en général opposés aux pauses inter-sprint qui encouragent à rattraper le retard accumulé au sein de la dernière itération.

En fonction des organisations, l’équipe a même parfois du mal à inclure au sein des itérations des tâches qui n’apportent pas de valeur fonctionnelle visible pour le PO. Alors, imaginer proposer un développement ou une expérimentation qui n’est pas directement lié au projet en cours, c’est souvent mission impossible.

Pourtant, les développeurs n’ont pas forcément besoin d’avoir le rôle de PO pour avoir des idées géniales. Que ce soient des idées purement techniques (nouvelles technos, intégration d’outils tiers, API, …) des idées d’amélioration des produits existants (nouvelles fonctionnalités, nouveaux usages) ou même des idées de nouveaux produits (produit interne pour faciliter tel ou tel workflow, nouvelle offre destinée aux clients de l’entreprise).

Alors pourquoi ne pas leur laisser un peu de temps pour s’y consacrer ?

Expérience en organisation libre

Chez RVIP, nous avons mis en place au sein de nos équipes de développement une journée “libre-organisation”, qui a lieu tous les 15 jours.

L’objectif de cette journée tel que nous l’avons définit et présenté à l’ensemble de l’entreprise, est d’améliorer la productivité et le bien-être des équipes en encourageant notamment :

• L’expérimentation
• La créativité et l’innovation
• L’auto-formation
• Le partage de connaissances

Concrètement, c’est une période durant laquelle l’équipe sort du workflow classique du ou des projets sur lesquels elle travaille au quotidien pour se consacrer à d’autres activités. Une seule contrainte, envoyer un mail collectif à toute la R&D en fin de journée, pour expliquer ce sur quoi elle a travaillé et ce qu’elle en a retiré.

Libre à elle alors, de laisser son imagination et sa créativité dicter cette journée de travail.

Les résultats après quelques semaines

Après quelques semaines d’expérimentation, le bilan est dans l’ensemble extrêmement positif.

En vrac, les équipes ont pu s’essayer et monter en compétences sur :

• Docker + écosystème (Rancher)
• Les bases de données orientées graph (Neo4J, OrientDB)
• Angular
• Elastic Search / ELK

Mais également :

• Entamer la refonte technique de différentes applications existantes
• Réaliser des POC d’applications hors de la Roadmap produits
• Prototyper une archi à base de Raspberry

Et certainement beaucoup d’autre choses que j’oublie.

Mais la montée en compétence sur un ensemble de technos n’est pas le seul bénéfice mesurable de ces journées en libre organisation. Elles sont presque toujours à l’origine d’un pic de motivation et de passion des équipes dont l’effet positif perdure bien au delà, au cours des semaines de développement SCRUM “classiques”.

Nous avons bien sûr aussi rencontré quelques écueils. Le principal étant sans doute le fait qu’il n’est pas facile de justifier et maintenir cette journée libre en période de rush.

D’autre part, il n’est pas non plus toujours facile de trouver une idée intéressante à expérimenter et de se lancer dessus sans le cadre d’une journée SCRUM classique.

Enfin, au delà de la R&D et des équipes produits, faire comprendre les objectifs et les intérêts de ce type d’expérimentation au reste de l’entreprise est un véritable challenge en soit.

Quelques pro tips

• Entamer cette journée par un brainstorm rapide sur les idées de l’équipe + vote de chacun
• Tout seul ou en équipe ? Privilégier le travail en équipe. C’est un moment de cohésion, presque de Team-Building
• Revenir ASAP dans un workflow agile type SCRUM pour la maintenance et les évolutions des produits éventuellement prototypés durant une ou plusieurs journées libres
• Faire des retours réguliers à la R&D mais aussi à l’ensemble de l’entreprise

Aller plus loin ?

Nous nous sommes concentrés jusqu’alors essentiellement sur des expérimentations purement techniques lors de ces journées libres.

Nous aimerions également en profiter pour tester de nouveaux workflows, de nouvelles méthodes de travail. Je pense par exemple au Mob Programming que Bertrand et son équipe ont expérimenté chez PMSI et dont le retour très intéressant est consultable ici.

Il serait également intéressant d’élargir l’expérience à d’autres services de l’entreprise. Je suis persuadé que, si les développeurs ont presque toujours des idées innovantes intéressantes pour l’entreprise, ils ne sont pas les seuls. Il serait génial de voir ce qu’une équipe commerciale par exemple ferait d’une journée en organisation libre…

Enfin, pourquoi ne pas aller encore plus loin en allouant un budget à ces journées libres et voir ce que les équipes sont capables de produire en ayant la responsabilité de le gérer et de l’utiliser dans le cadre définit ci-dessus : expérimentation, créativité et innovation, auto-formation et partage de connaissances.