Comment gérer les impératifs de production (incidents, sollicitations non prévues) sans impacter le focus sur les sujets fonctionnels ? Une équipe de shérifs a été mise en place pour traiter les demandes transverses au sein du projet pass Culture.
Le pass Culture fait partie des engagements de campagne du président de la République Emmanuel Macron. Concrètement, il s’agit d’une aide financière de 300€ offerte aux jeunes de 18 ans pendant 24 mois afin de les aider à prendre leur autonomie sur leurs pratiques culturelles et à les diversifier. Depuis mai 2021, l’application devient accessible à tous, quel que soit l’âge et a pour ambition de devenir le GPS de la culture de toutes les générations, avec déjà à son compteur plus de 6 millions d’offres. Les équipes de développements sont organisées en “squads” au pass Culture. Elles sont composées de 3 à 5 développeurs, un Product Owner (PO) et un UX/UI Designer qui prennent en charge la réalisation d’une fonctionnalité de bout en bout, du cadrage à la mise en service.
Dans cette composition, comment gérer le flux de demandes support dû à la croissance rapide du nombre d’utilisateurs ? A qui attribuer les demandes diverses et transverses qui ne rentrent pas dans le périmètre des squads en cours ? Autrement dit : comment assurer une productivité maximale des développeurs dans leur squad fonctionnelle tout en gérant avec réactivité, en parallèle, la correction des bugs en production, les mises en production, les investigations suite à des demandes de support… ?
En réponse à ces problématiques, une squad shérif, dédiée à la résolution de demandes annexes et sujets transverses a été créée. Composée de 2 POs fixes et de 3 développeurs (sur 20) prenant place à tour de rôle, cette nouvelle organisation a permis au fil des mois de répondre à deux enjeux essentiels : favoriser la concentration des équipes sur les sujets priorisés en limitant les changements de contexte, et traiter efficacement les tâches annexes.
Un an après la mise en place de ce système, nous partageons un retour d’expérience de cette expérimentation.
La squad occupe les responsabilités suivantes :
La squad des shérifs est tournante. Chaque itération (donc chaque semaine), 3 développeurs (sur un total de 20) sont détachés de leurs squads respectives pour rejoindre la squad des shérifs. Sortir de sa squad a un coût pour chaque développeur : il laisse temporairement ses sujets en cours pour s'approprier de nouveaux tickets. La mise en place d’un calendrier partagé a permis d’anticiper la présence de chacun sur le poste de shérif en fonction des possibles absences (vacances, congés, formations,...) et ainsi d’anticiper toute mauvaise surprise organisationnelle sur ce poste qui demande un fort investissement à temps plein. Le calendrier de rotation permet aux POs de chaque squad d’anticiper la capacité de production en fonction des présences.
La squad shérif compte 2 POs qui sont responsables de la priorisation du backlog shérif qui s’alimente de demandes pouvant provenir de différentes sources :
Les POs shérif sont également responsables du bon déroulé des mises en production, du suivi des alertes remontées quotidiennement et de la bonne communication autour de celles-ci. Ils sont le point de coordination entre l’équipe de développement, le support et toutes les parties prenantes du projet (équipe communication, équipe produit…).
Nous avons envoyé un sondage à l’ensemble de l’équipe de développement pour recueillir leurs impressions sur le rôle de shérif :
Les shérifs ont permis d'éviter le context switching pour se concentrer uniquement sur leurs tâches et objectifs de squad.
Ils reconnaissent devenir de plus en plus autonome sur les produits du pass Culture
Chaque membre de l’équipe de développement sait désormais faire une mise en production, et, si un nouvel arrivant rejoint l’équipe, il peut facilement binômer avec un shérif plus expérimenté pour le faire monter en compétences.
‘Grâce aux shérifs je peux rester au contact mais surtout être confronté à la production. Je garde conscience des problèmes des différents environnements’
Devenir shérif pour une itération leur permet de quitter leur environnement respectif et de découvrir de nouvelles facettes des applications du pass Culture. Cela favorise la polyvalence et le développement de la connaissance générale sur les différents produits.
‘Je peux également découvrir des champs fonctionnels et techniques inconnus que je n’ai pas le temps de faire avec mon équipe en temps normal’
Ce rôle tournant contribue également à partager les pratiques entre des développeurs qui ne travaillent pas dans la même équipe ou encourager le mentoring.
‘ Etre shérif m’a permis de travailler avec d'autres personnes du pass que je n’avais encore jamais rencontré jusqu’alors’
‘La première semaine où j'ai été shérif c'était passionnant car j'ai découvert plein de trucs mais j'étais largué, heureusement qu’un mentor est venu m’épauler’
Réactivité face aux demandes de support urgentes.
‘Je reste également au contact de mes utilisateurs en découvrant les problématiques qu’ils rencontrent ou remontent au support’
Bien que ce rôle soit bien accueilli au sein de l’équipe, nous faisons face à certaines difficultés :
Les développeurs sont contraints de quitter leurs squads respectives pour se consacrer 100% au rôle de shérif. Cela nécessite donc une certaine organisation : s’assurer qu’une autre personne de sa squad soit disponible pour reprendre les développements en cours.
De même, à la fin d’un roulement, certaines tâches peuvent nécessiter du travail supplémentaire et les shérifs sortants doivent transmettre leurs connaissances sur la problématique et leur état d’avancement. De leur côté, les nouveaux shérifs doivent s’approprier la solution technique. Une stratégie technique qu’ils auraient parfois pensée différemment…
‘C’est parfois désagréable de reprendre les tickets qui ont été commencés par la squad shérif précédente quand elle manque de rigueur sur l’indication du travail effectué, La transition vers la semaine shérif peut être complexe et douloureuse (un ticket à passer, une dernière revue à prendre en compte, etc.)’
Du côté des POs shérifs, traiter les demandes support entrantes peut vite devenir chronophage. Les items du backlog shérif peuvent être créés par n’importe quel membre de l’équipe, il est donc compliqué de s’approprier le cadrage de certains tickets sans se synchroniser avec d’autres personnes.
Un premier bilan de l’activité shérif a été réalisé au bout de 6 mois. Les tâches réalisées jusque là se répartissaient entre tâches support (63%), bugs (17%), User Story (9%), tâches techniques (10%).
Les tâches support sont pour la plupart des actions manuelles répétitives. Il était temps d’investir dans l’automatisation de celles-ci afin de dégager du temps pour se consacrer à des sujets à plus forte valeur ajoutée. Nous avons créé une squad chargée de l'automatisation des processus internes qui a pour objectif de rendre autonome l’équipe support sur les tâches récurrentes. La priorisation des actions à automatiser a pris en compte deux critères : la récurrence des demandes et leur pénibilité.
Les tâches shérif sur les 3 derniers mois se répartissent entre support (41,9%), bugs (16,7%), User Story (21,4%), tâches techniques (18,1%).
On constate que le pourcentage des demandes support a diminué de 20%. Le temps gagné en optimisant certaines de ces tâches a permis de consacrer plus de temps aux évolutions fonctionnelles en passant de 9 à 20% de l’activité shérif.
Voici ce que nous avons mis en place pour faciliter les roulements :
Pour le suivi quotidien :
Pour l’amélioration continue :
Publications liées à date au pass Culture :