La croissance d’un Produit s’accompagne généralement d’une augmentation des effectifs. On se retrouve alors à structurer une première squad et à devoir ensuite en créer une deuxième, puis 5, 10, voire plus.
Des modèles d'organisation vont alors émerger, des organisations verticales ou hybrides par exemple.
Les difficultés commencent à partir de 2 équipes, même si elles peuvent être résolues relativement rapidement à ce stade. Mais chaque palier ou changement d’organisation peut faire apparaître son lot de nouveaux problèmes - ou amplifier les problèmes existants.
Entre éparpillement de la vision, dépendances techniques ou organisationnelles et télescopages involontaires, les squads se retrouvent à devoir gérer des situations qui les ralentissent et rendent leur quotidien désagréable. En conséquence, votre time to market s’allonge (chaque équipe étant impactée par les éventuels retards des autres équipes), la prédictibilité baisse, les équipes se lassent et dans le pire des cas la qualité de votre Produit se détériore.
En effet, créer une nouvelle squad équivaut inévitablement à multiplier le nombre de liens à gérer avec le reste de l’organisation. Il existe 2 types de liens :
- la dépendance : une squad n'est pas autonome pour délivrer sa roadmap ou atteindre ses objectifs car une autre équipe doit réaliser une activité pour qu'elle puisse y parvenir.
- l’adhérence : une squad est autonome sur son périmètre mais son travail peut impacter le travail d’autres squads, et les 2 devront s’aligner pour garantir une cohérence globale de l'expérience utilisateur ou de la solution technique.
Dans ce chapitre, nous allons nous intéresser dans un premier temps aux différents types de dépendances et adhérences pouvant exister dans une organisation Produit de type verticale avec des équipes autonomes et multi-disciplinaires et vous proposer des pratiques qui vous permettront de les atténuer. Nous parlerons ensuite des principales dépendances et adhérences constatées dans des organisations hybrides ou moins avancées dans leur transformation, et vous proposerons des pistes de solutions pour chacune.
Dépendances, adhérences et leviers à actionner dans une organisation Produit verticale
La suite de cet article fait le focus sur les organisations Produit verticales. Si vous êtes intéressé par les organisations hybrides, consultez plutôt la partie 2 : Focus sur les organisations hybrides (partie 2/2)"
1. Gestion des dépendances et adhérences entre squads Produit
Dans un modèle vertical, il est fréquent qu’une squad ait besoin qu’une autre squad développe une fonctionnalité, un socle technologique ou corrige un bug avant de pouvoir mettre en production sa propre fonctionnalité : il s’agit d’une dépendance forte. Par exemple, si une squad ayant pour objectif d’améliorer la communication avec l’utilisateur a choisi de prioriser dans son backlog une refonte totale du système d’envoi d’emails, les autres squads qui souhaiteraient travailler sur le contact par email avec l’utilisateur devront sans doute attendre que le nouveau module soit terminé, ou mettre la main à la pâte en aidant au développement.
Pour ce qui est des adhérences entre ces mêmes squads, elle surgissent notamment lorsque plusieurs squads travaillent en parallèle sur des sujets impactant un même cas d’usage donc un même parcours utilisateur. Si ces équipes ne communiquent pas correctement, l’expérience utilisateur peut en être pénalisée. Par exemple, dans le cas d’un service de streaming musical, la squad “playlist” pourrait choisir d’afficher une pop-up de confirmation chaque fois que l’utilisateur supprime une chanson de sa playlist ; tandis que la squad “librairie” pourrait prendre le parti de supprimer directement la chanson puis d’afficher une notification contextuelle permettant d’annuler l’action a posteriori.
Le résultat n’est pas bloquant, chaque équipe pouvant développer et mettre en production sa fonctionnalité, mais l’expérience utilisateur s’en trouve dégradée à cause des incohérences, petites ou grosses, qui finissent par apparaître.
Il est possible de passer outre certaines incohérences en contractant de la dette technique ou de la dette Produit pour livrer coûte que coûte, mais il ne s’agit pas d’une solution pérenne : sur le long terme, les désynchronisations entre squads coûtent cher.
Ce type de dépendances est souvent inévitable : il s’agit du corollaire de l’autonomie laissée aux équipes. Une organisation verticale ne résoudra donc pas magiquement la coordination entre les équipes : il est nécessaire d’actionner un certain nombre de leviers afin de faire en sorte que le Produit reste cohérent dans son ensemble et que la collaboration entre les squads soit fluide et non cloisonnée. Nous préconisons de ne pas appliquer d’un seul coup l’ensemble de ces solutions mais de choisir celles qui conviennent le mieux à votre organisation, car implémenter toutes ces pratiques en même temps pourrait se révéler très chronophage pour vos équipes.
Levier 1 : Créer une instance d’arbitrage de la roadmap globale
La “kermesse” (terme emprunté à Deezer) est une instance de partage et d’arbitrage de la roadmap organisée avant le début de chaque trimestre. Cet atelier permet à chaque squad de présenter sa roadmap, de l’expliquer aux autres équipes et aux parties prenantes et de discuter ensuite les priorités.
La “kermesse” de Deezer
Deezer a de nombreuses équipes, qui sont regroupées en “start-ups”. Une start-up est ici un domaine particulier du Produit (exemple : Product Features, Core App, Platform).
Chaque start-up possède ses propres objectifs business et sa roadmap interne. Ces objectifs et ces roadmaps sont globalement discutés avec les différentes parties prenantes (comité de direction, Marketing, Ventes, technique, Produit) lors d’un événement d’une demi-journée, dénommé la “kermesse”. La kermesse se déroule en 3 temps.
Au départ, les responsables de chaque start-up montent un stand (d’où le nom donné à l’atelier) où ils exposent visuellement leur roadmap pour les 3 mois à venir. Puis ils visitent les stands de leurs homologues. Cela permet de créer de la transparence et de la discussion.
Ensuite, les autres participants entrent dans l’arène : tout le monde se réunit et la kermesse commence. Les responsables de start-up accompagnés de leurs équipes doivent alors défendre leur roadmap en expliquant pourquoi ils priorisent certaines fonctionnalités ou chantiers techniques au détriment d’autres, tout en matérialisant la capacité maximale de réalisation pour le trimestre qui démarre. Des négociations ont lieu, et les roadmaps sont ajustées au fil des échanges.
A la fin, les responsables réalisent une rétrospective pour améliorer le format des ateliers de la kermesse.
Ce format fun, mêlant structure et chaos, a l’avantage de réunir tout le monde dans le même espace, de donner une voix à chacun, de confronter les visions et d’aligner les équipes. Il s’agit d’un beau mélange de bottom-up et top-down.
Levier 2 : Mettre en place des instances de planification et de gestion des dépendances périodique (ex. le PI Planning)
En plus d’une instance servant à partager et discuter la roadmap (telle que la “kermesse”), il est nécessaire de mettre en place des instances de planification et de synchronisation périodiques dédiées notamment à la gestion des dépendances. C’est par exemple ce que propose SAFe avec le PI Planning : tous les 4 ou 5 sprints, l’ensemble des squads se réunit sur 1 à 2 journées complètes pour exposer chacune leur plan validé pour les prochains sprints. Puis elles identifient au cours d’un atelier l’ensemble des dépendances à anticiper, et les impacts éventuels sur la roadmap. Une telle réunion peut paraître chronophage et difficilement gérable, mais notre expérience montre que réunir physiquement l’ensemble des parties prenantes autour du Produit est le meilleur moyen de procéder ; une fois les squads alignées, et les différents Product Managers au clair sur les priorités du Produit, le temps économisé sur la globalité du processus est très important.
On ne rappellera jamais assez qu’il est nécessaire que l’ensemble des Product Managers ait réalisé en amont du PI Planning un vrai travail de conception Produit (voir chapitre 6 “Comment industrialiser le Product Discovery ?”) et qu’ils présentent une roadmap dérisquée et claire pour les 4 / 5 sprints à venir afin d’assurer un PI Planning efficace.
Levier 3 : Implémenter un outil de planification visuel tel que le Program Board
Le Program Board (outil emprunté à SAFe) est un outil visuel où les dépendances identifiées pour les prochains sprints sont matérialisées par des ficelles reliant les différents éléments ou sujets potentiellement bloquants. Ce tableau peut être créé par exemple chaque début de trimestre lors du PI Planning, mis à jour à chaque sprint et les ficelles coupées au fur et à mesure que les dépendances sont traitées.
Levier 4 : Constituer un design kit
Le design kit permet aux squads de fixer les bonnes pratiques UX et UI au niveau du Produit et de créer une bibliothèque de composants mutualisés, le tout en déclinant la charte graphique et la plateforme de marque. Le design kit garantit la cohérence du Produit et fait gagner du temps à toutes les squads en encourageant la réutilisation et la mutualisation des composants ; si votre framework de développement front-end est lui aussi orienté composant, le design kit peut même inclure du code source réutilisable directement par n’importe quel développeur.
Levier 5 : Mettre en place un management visuel axé sur l’expérience utilisateur (Experience Board)
Chaque squad peut afficher sur un tableau les écrans sur lesquels elle compte travailler dans les prochains sprints, regroupés par persona. En consultant ce tableau, les membres des squads peuvent anticiper les potentiels écarts d’expérience utilisateur liés à leurs travaux respectifs, et s’assurer de la cohérence des parcours pour un même utilisateur.
Levier 6 : Mettre en place des communautés de pratique
Comme expliqué dans le chapitre 3 sur le découpage des équipes produit, le chapter est une communauté de pratiques autour d’un domaine d’expertise ou d’un métier commun (Design, Product Ownership, iOS, back-end, etc.), alors que la guild est une communauté de personnes partageant un intérêt pour un sujet en particulier (automatisation des tests, monitoring, sécurité, etc...). La mise en place de ces communautés permet de partager les bonnes pratiques, d’identifier les adhérences et de les traiter avant qu’elles n’impactent démesurément le Produit.
Le chapter “Design” peut par exemple construire et faire vivre le design kit, tandis que le chapter “Product Ownership” ou “back-end” peut garantir l’homogénéité des choix techniques effectués au sein des squads.
En plus des chapters et des guilds, Airbnb a par exemple mis en place des Experience Groups transverses. Les membres des squads ont un double rattachement : d’une part à leur squad (Growth, Booking, et Reviews), et d’autre part à un groupe d’expérience en charge d’assurer la cohérence de l’expérience des utilisateurs en se réunissant autour des deux principaux personae du Produit : les hôtes et les visiteurs.
Levier 7 : Créer un poste de Program Manager
Le rôle du Program Manager consiste à mettre de l’huile dans les rouages de l’organisation et porter des projets transverses en synchronisant les différents Product Owners / Product Managers des squads, tout en assurant une cohérence sur ce qui est mis en production.
Levier 8 : Mettre en place un processus d’open source interne
Voici une pratique qui a été expérimentée au sein des équipes OUI.sncf que nous recommandons : chaque équipe est propriétaire d’une portion de la base de code (celle correspondant à son périmètre). D’autres équipes peuvent effectuer des commits (demandes de modification du code source), mais seule la squad propriétaire peut valider l’intégration de ces modifications en production. Cette technique permet à chaque squad de travailler sur n’importe quelle partie du code, tout en maintenant un contrôle de cohérence et de qualité incarné par l’équipe la plus appropriée.
Levier 9 : Implémenter des OKR
Les OKR, expliqués en détail dans le chapitre 2, sont un vecteur important d’alignement entre les squads : en rendant les priorités transparentes et en alignant les objectifs des différents acteurs, ils permettent de simplifier les instances évoquées précédemment (kermesse, PI Planning) et de s’assurer que tout ce qui sera proposé par les squads sera conforme à la stratégie globale de l’entreprise.
2. Gestion des dépendances entre une squad et une équipe transverse (RH, achats…)
Les dépendances avec les équipes transverses à l’entreprise sont nombreuses et il s’agit clairement de services et de rôles qui ne peuvent être intégrés à chaque squad. Il serait en effet absurde de préconiser l’intégration permanente d’un responsable RH ou juridique dans chacune des squads.
Les dépendances que nous avons observées lors de nos différentes missions sont liées à des besoins de recrutement ou de renforcement des équipes avec une forte dépendance vis-à-vis des services RH et achats (recrutement en interne ou en externe), ou à des besoins d’expertise juridique ou ad’hoc.
Le prix à payer est le même que pour les autres dépendances : le time to market s’allonge et la prédictibilité de livraison diminue lorsqu’une squad manque de ressources et qu’elle n’est pas maître de ce paramètre. Une équipe à qui il manque un développeur ou un Product Designer verra un goulot d’étranglement se créer.
Nous proposons différentes solutions pour gérer au mieux ces dépendances inhérentes à toute organisation.
Levier 1 : Être délégataire de certaines activités réalisées par les services RH ou achats
Lorsque le recrutement de nouvelles ressources devient de plus en plus long et problématique pour les squads, nous conseillons de réaliser un atelier conjoint entre les équipes RH et les squads, de décomposer les activités clés du processus de recrutement et de s’accorder sur un niveau de délégation pour chacune d’entre elles. Les équipes peuvent ainsi faire recruter les profils manquants au sein de leur squad plus rapidement.
Un processus classique se décomposerait par exemple de la manière suivante :
rédaction des offres d’emploi > publication des offres d’emploi > sourcing des candidats > qualification et tri des CV > contact des candidats > organisation des entretiens > réalisation des entretiens > proposition d’offre d’emploi > négociation des conditions de l’offre > remise du contrat de travail
Le service RH peut, par exemple, déléguer les premières étapes du processus à chacune des squads afin de fluidifier et d’accélérer le recrutement. Cette technique peut également être appliquée au service Achats pour le recours à une prestation externe.
Levier 2 : Négocier un budget de prestation à gérer en toute autonomie
Les squads font souvent appel à des prestataires externes afin de compléter les équipes avec les compétences et profils manquants. Ainsi, négocier un budget de prestation à l’année ou au semestre que chaque squad puisse gérer de façon autonome permettrait de fluidifier le recrutement des ressources externes.
Le processus et les exigences de recrutement des profils externes peut également être décomposé tel que décrit auparavant.
Levier 3 : Intégrer ponctuellement des expertises spécialisées au sein des squads concernées
Imaginons qu’une équipe ait un focus juridique ou réglementaire important lors de 4-5 sprints ou lors d’un trimestre ; dans ce cas, nous conseillons d’intégrer ponctuellement cette expertise à la squad. Nous préconisons que cette personne rejoigne physiquement l’équipe afin d’y être intégrée pleinement, et d’éviter la perte d’information et les allers-retours.
Si cette expertise concerne l’ensemble des squads, par exemple un expert RGPD (le sujet de l’année 2018 pour plusieurs organisations), nous préconisons d’utiliser le PI Planning tel que décrit précédemment pour y convier des spécialistes du sujet et d’aligner toute l’organisation autour de cet enjeu majeur.
Dans cette 1ère partie nous avons donc proposé des solutions pour résoudre les problèmes de dépendance dans une organisation verticale.
Dans la partie 2, nous avons réalisé le même exercice pour les organisations hybrides.
