%20(1).jpg)
Camille
Toute équipe produit comportant plusieurs squads est sujette aux dépendances. La gestion de ce sujet est primordiale pour assurer qualité et cohérence produit, mais aussi la livraison au temps opportun de fonctionnalités. Mal gérées, les dépendances peuvent occasionner de véritables difficultés, et avoir des impacts financiers et humains non négligeables. Le Product Ops est un atout essentiel dans la gestion des dépendances et dans l’organisation du travail.
Il existe principalement deux types de dépendances :
Il est primordial, lorsque plusieurs équipes sont amenées à travailler sur un même produit, d’identifier si les dépendances sont absolues ou relatives, car leur gestion s’effectuera différemment. Leur priorisation en sera aussi impactée.
Une gestion incomplète ou désorganisée des dépendances entraîne plusieurs écueils, qui peuvent se lire comme autant de causes à effets :
Ces éléments témoignent de l’importance de prendre à bras le corps le sujet de la gestion des dépendances.
Afin de limiter les frictions liées aux dépendances et d’accélérer leur traitement, certaines bonnes pratiques simplespeuvent être très utiles. Faire appel à un Product Ops pour favoriser l’organisation du travail paraît indispensable.
Par ailleurs, lorsque plusieurs squads travaillent en parallèle, il est nécessaire de s’assurer qu’elles parlent le même langage. Pour ce faire, il faut que leurs pratiques soient uniformisées.
Il est notamment primordial que ces squads soient organisées selon le même temps de sprint, et aient la même dénomination pour leur sprint. Cela leur permettra de pouvoir coordonner leur travail, et ainsi de s’organiser plus aisément.
Les boards de sprint doivent être accessibles par toutes les équipes, sur un seul et même outil, ainsi que les roadmaps, afin d’être consultables par n’importe qui.
Afin de permettre des intégrations plus rapides des éléments d’une autre équipe, il est primordial que l’entreprise ait défini au préalable un design system unique. Le design system correspond à l’ensemble des éléments de design d’une entreprise : c’est une forme de charte graphique, une bibliothèque de composants, permettant de trouver une solution pour chaque nouvel élément, en s’assurant de sa cohérence graphique globale. De façon très fondamentale, cela permet par exemple d’avoir des call-to-actions primaires et secondaires similaires, mais aussi des pop-in semblables d’une squad à l’autre.
Le bénéfice utilisateur en est assez évident : le parcours utilisateur est uniforme et cohérent, ce qui facilite largement la navigation.
L’uniformisation des technologies utilisées est aussi un moyen de réduire les dépendances : les équipes techniques seront capables de parler le même langage et certains développeurs pourront même être transférés momentanément d’une équipe à une autre, si nécessaire, afin d’accélérer la mise en synergie de deux équipes dépendantes.
Certaines pull-request pourront même être revues par des développeurs d’autres équipes, notamment en cas de dépendances relatives, afin de s’assurer qu’une fonctionnalité développée n’a pas d’effet de bords négatifs sur une autre équipe.
Afin de mieux anticiper et gérer les dépendances, il est possible d’instaurer des rituels réguliers entre l’ensemble des squads produit, afin de pouvoir présenter sa roadmap aux autres équipes.
Ainsi, certaines entreprises choisissent de s’organiser en cycle de 3 à 6 mois. En amont de ces cycles, les entreprises priorisent des « initiatives » sur lesquelles elles s’engagent à aboutir durant les 3 à 6 mois. Ces initiatives sont présentées lors d’ateliers de plusieurs jours où toutes les équipes produit sont présentes.
L’exercice à effectuer est un exercice en entonnoir. Chaque équipe part de l’initiative finale, par exemple « Déployer un algorithme de recommandations sur la plateforme ». De cette initiative découle plusieurs EPICs, qui englobent elles-mêmes diverses user stories. Chaque équipe présente aux autres son initiative, les grands jalons pour la mener à bien, et sa roadmap prévisionnelle. Cela permettra aux autres équipes de pouvoir se manifester si elles identifient des dépendances avec leur propre équipe, non anticipées par l’équipe présentant sa roadmap.
Chaque équipe pourra alors indiquer au sein de ses fonctionnalités les dépendances à prévoir : les roadmap pourront être revues en conséquence, après s’être concerté avec les autres équipes sur les délais envisageables de traitement des dépendances.
Certains framework de travail facilitent l’identification et la gestion des dépendances.
C’est le cas du framework Scrum, qui, grâce à son fonctionnement en sprints, permet d’identifier à chaque nouveau sprint les dépendances.
Le framework SAFe est une réplique de la méthodologie Scrum mais à l’échelle de plusieurs équipes. Elle favorise l’homogénéité et la cohérence des pratiques produit, prévoit des instances dédiées de présentation et d’organisation du travail à l’échelle de l’entreprise.
Au sein d’un framework SAFe, les équipes se réunissent régulièrement, toutes les 5 à 10 semaines, afin de réaliser un PI Planning, permettant de synchroniser les équipes sur leur roadmap, de donner de la visibilité aux autres équipes, mais aussi de lever les dépendances.
Toute structure produit accueillant plus de deux équipes produit est sujette aux dépendances. Ce sujet majeur, s’il est mal géré, occasionne de nombreuses difficultés, que ce soit l’allongement des délais de livraison, des frictions entre équipes, mais aussi des déboires financiers.
Afin de gérer au mieux les dépendances inter-équipes, voici quelques étapes à respecter :
.jpg)
.jpg)
