La série de Comptoirs OCTO x pass Culture touche à sa fin ! Cet article vous fait faire un tour d’horizon de ce qui s’est passé, avec tous les liens pour visionner les replays et accéder au contenu.
Afin d’introduire le sujet, le pass Culture est une mission de service public qui a pour but de renforcer et diversifier les pratiques culturelles des jeunes de 18 ans en leur donnant 500€ à dépenser dans la culture.
Ce comptoir est fait pour vous si vous souhaitez en apprendre davantage sur le passage d’une start-up d’Etat à une structure SAS et si vous souhaitez comprendre comment se fait la co-construction d’un produit quand celui-ci est à destination d’un public aussi varié et exigeant que : les jeunes de 18 ans, les acteurs culturels et les réseaux socio-éducatifs et politiques.
Ce comptoir est également l’occasion de rencontrer les directeurs du delivery et du produit, ainsi que le Partner secteur public d’OCTO qui vous livrent leurs clés du succès pour un tel projet !
Support de slides : https://www.slideshare.net/OCTOTechnology/le-comptoir-octo-pass-culture-1-244939616
Ce deuxième comptoir présente les différentes organisations de l’équipe de delivery agile qu’a expérimenté le pass Culture.
Cette prise de recul permet de balayer les différents éléments déclencheurs, les dispositifs ainsi que les avantages et inconvénients de chaque organisation.
Le projet démarre après l’élection d’Emmanuel Macron suite à sa promesse électorale concernant la création d’un pass Culture de 500€ pour les jeunes de 18 ans. Le format de start-up d’Etat est mis en place afin de se donner un maximum de souplesse et la nouvelle équipe (qui se compte sur les doigts d’une main) a besoin d’expérimenter rapidement afin de commencer à construire et valider ses premières hypothèses produit. L’équipe de développement est petite (3 à 4 personnes) et fonctionne en totale auto-organisation avec un outillage simple (Issues Github). À ce moment-là du projet, la méthodologie agile est minimale, il y a très peu de rituels, mais cela permet un démarrage rapide du projet.
L’équipe pass Culture commence à grandir : elle passe de 2 développeurs et 1 UX/UI Designer à une petite dizaine de personnes sur le projet. Elle doit également valider sa première expérimentation avec 10 000 utilisateurs tests.
Devant de telles ambitions et confronté aux premiers problèmes de communication et de partage d’informations qui émergent avec une équipe plus conséquente, le pass Culture intègre un Product Owner (PO).
Cette phase permet la mise en place de plusieurs rituels et outils pour structurer l’équipe :
Mise en place d’itérations d’une semaine, avec les rituels de daily meeting et rétrospective,
Création d’un véritable backlog avec notamment l'outil JIRA pour suivre la réalisation des fonctionnalités, bugs et tâches techniques,
Création d’un rituel hebdomadaire de démonstration produit pour que chaque personne de l’équipe puisse suivre les avancées fonctionnelles et techniques et faire des feedbacks sur ce qui a été réalisé.
L’équipe de développement est maintenant composée de 10 personnes, le périmètre fonctionnel ne cesse de croître et il devient compliqué pour un seul PO de prendre de l’avance sur le backlog pour rédiger et prioriser les tickets. L’ajout d’un second PO est donc décidé et il faut maintenant découper l’équipe intelligemment afin de ne pas se marcher sur les pieds.
L’idée de passer aux Component Teams fait son chemin. Dans une Component Team, chaque équipe est responsable d’un composant bien précis dans la création du produi****t. Les équipes peuvent être structurées selon une logique technologique (par exemple “front” et “back”), par canal (web, mobile, IoT…) ou par couche applicative donnée (socle de paiement, service d’emailing…).
Au pass Culture, le découpage par produit s’est naturellement imposé avec une équipe “app mobile” pour concevoir le produit à destination des jeunes de 18 ans et une équipe “espace PRO” pour construire le portail web à destination des acteurs culturels.
Cette organisation permet à chaque PO d’être autonome sur son périmètre et aux développeurs de monter en compétence sur un aspect du produit en développant leur expertise. Les périmètres étant clairs pour tous, les priorités sont plus faciles à identifier.
L’équipe de développement est désormais composée de 15 développeurs. À l’échelle d’une Component Team, le coût de communication et de coordination entre les personnes augmente et finit par entraver progressivement l’activité de l’équipe qui a du mal à prioriser les sujets et traiter des fonctionnalités de bout en bout.
À l’échelle du projet, la cohésion et la communication se perdent entre les deux Component Teams. Le flux de demandes support est croissant en vue de l’augmentation du nombre d’utilisateurs. Assurer une réactivité à ces demandes et traiter les sujets transverses devient de plus en plus complexe.
Les Component Teams sont donc abandonnées au bout de 9 mois pour des Feature Teams qui sont des équipes multidisciplinaires autour d'une macro-fonctionnalité.
Appelées “squads” au pass Culture, ces petites équipes composées de 2 et 5 développeurs, d’un UX/UI et d’un PO, prennent en charge la réalisation d’une fonctionnalité de bout en bout, du cadrage à la mise en service. Après avoir livré l’incrément de valeur, la squad est destituée au profit d’une nouvelle… et ainsi de suite.
Les développeurs font partie d’une seule squad mais les PO et UX/UI prennent en charge plusieurs squads.
Pour assurer une productivité maximale des squads tout en gérant en parallèle un certain nombre de tâches annexes (mises en production, investigations suite à des demandes de support, etc.), un rôle de développeur “shérif” a été imaginé.
L’équipe des shérifs est tournante. Chaque itération (donc chaque semaine), 2 développeurs (sur un total de 18) sont détachés de leurs squads respectives pour rejoindre l’équipe des shérifs. Ils seront responsables pendant une semaine de la gestion des problématiques de la production, des sollicitations du support et des demandes transverses.
Le pass Culture continue à grandir - sa pérennité étant assurée à date, le projet se dote d'objectifs ambitieux : continuer l'ouverture des départements pour généraliser à toute la France, sachant que 800 000 jeunes ont 18 ans tous les ans, et que le pass Culture est valable 2 ans. Le pass se constitue ainsi en société afin de gagner en autonomie et se retrouve soumis aux règles des marchés publics. Un appel d’offre est lancé courant 2020 avec la séparation du marché en 3 lots :
Un lot 1 pour le développement technique avec 3 attributaires.
Un lot 2 pour la direction produit et le pilotage mission (PO, UX, Delivery manager) avec 1 attributaire.
Un lot 3 pour tous les enjeux data avec 2 attributaires.
Le projet vit alors une véritable petite révolution : passage de 1 à 5 attributaires avec des cabinets aux cultures d’entreprises et méthodes différentes et doublement des effectifs : nous passons de 15 à 30 développeurs, de 2 à 6 POs et de 2 à 5 UX/UI !
Notre organisation se trouve donc obligée de changer d’échelle et émerge l’idée de faire des Stream Aligned Teams. Les Stream-aligned teams sont des équipes alignées avec les priorités actuelles du produit, bénéficiant de compétences cross-fonctionnelles et pouvant livrer des incréments de valeur sans attendre les autres équipes.
Le principe des squads demeure, ainsi que le rôle des shérifs, la différence notable avec la précédente organisation est la création de "streams" qui englobent les squads. Ces streams suivent d’ailleurs des objectifs trimestriels liés aux objectifs du pass Culture (par exemple concernant l’acquisition et la rétention des utilisateurs, ainsi que le taux de diversification culturelle).
Ci-dessous l’organisation à date de l’équipe de Delivery du pass Culture :
Après avoir itéré et évolué sur les modèles d'organisation de l’équipe de delivery agile du pass Culture, voici les principaux enseignements marquants que nous en retenons :
S'informer sur les modèles d’organisations d'autres sociétés pour trouver de l’inspiration.
Être conscient que ce qui a bien fonctionné pour la société X ne fonctionnera pas forcément pour pour la société Y : tout modèle d’organisation doit être adapté au contexte du projet.
Test and learn : tester des choses pour s'approprier un modèle, savoir reconnaître quand ça ne fonctionne pas et adapter pour ajuster.
Se demander au bout d’un certain temps si la configuration est toujours la bonne : il n'y a pas de modèle figé dans le temps quand on parle d’organisation.
Ne pas changer d’organisation trop fréquemment, car les changements perpétuels peuvent être coûteux pour l'équipe.
Arriver à une organisation sur-mesure pour sa société.
Replay épisode 2 : https://www.youtube.com/watch?v=NLqAXvIz66Y
Slides episode 2 : https://www.slideshare.net/OCTOTechnology/le-comptoir-octo-pass-culture-2
Si le projet et le produit pass Culture vous intéressent, nous avons listé toutes les publications liées à date :
Article “La livraison d’une fonctionnalité n’est pas la fin de la co-construction avec les utilisateurs – exemple du pass Culture : https://blog.octo.com/la-livraison-dune-fonctionnalite-nest-pas-la-fin-de-la-co-construction-avec-les-utilisateurs-exemple-du-pass-culture/
Article “Sortir de sa bulle : diversifier les recommandations d’offres culturelles” : https://blog.octo.com/sortir-de-sa-bulle-diversifier-les-recommandations-doffres-culturelles/
Comptoir “Construire une app mobile avec et pour des jeunes de 18 ans”
Le blog produit du pass Culture : https://medium.com/passcultureofficiel