Dans ce post, je vais vous parler de ma méthode de travail pour trouver un équilibre entre la méthodologie agile et UX. Je partagerai également les outils que nous utilisons pour gérer nos backlogs et prioriser nos tâches. En ce moment, je suis très impliqué dans la mise en place d'un nouveau modèle chez mon client pour établir la manière dont nous travaillons. Cela correspond à du “Dual-Track Agile” ou encore une méthodologie de “Product Discovery / Product Delivery”. On n’est pas très loin non plus d’une méthode Shape Up de Basecamp. En gros, nous avons deux axes de fonctionnement parallèles : La partie implémentation et développement qui fonctionne en mode scrum classique avec des sprints de développement, où nous intervenons pour ajuster les éléments de design et gérer les tests utilisateurs en cours de sprint. En parallèle, nous travaillons sur la recherche et la découverte, qui ne fonctionne pas en sprint car cela peut prendre du temps variable en fonction des besoins et des activités, parfois une semaine, parfois un mois. Nous utilisons une approche plus classique pour la recherche, en gérant un backlog de découverte et en traitant les priorités à l’aide d’un Kanban. Une fois traités, les sujets de recherche testés et validés sont finalisés sous forme de story et quittent le backlog de découverte pour aller nourrir le backlog de développement. Nous intervenons ensuite assez peu dans le flux de développement, uniquement pour les petits ajustements nécessaires en cours de route. Une fois que les éléments sont ancrés, nous gérons les tests et les retours pour nourrir le backlog de découverte. Cela nous permet de travailler sur ces deux modèles en parallèle, avec deux "lignes de production" distinctes sur lesquelles nous travaillons. Ce mode de fonctionnement fonctionne plutôt bien pour nous, mais le plus important à retenir c’est qu’aucun framework n’est parfait. Il faut souvent adapter un modèle au contexte de l’entreprise et du projet / produit sur lequel on travaille car chaque sujet est différent et les équipes ont une culture et une expérience différentes. Si on ne prend pas en compte ce contexte et qu’on cherche à appliquer une méthode, quelle qu’elle soit, au pied de la lettre, c’est le meilleur moyen de se prendre le mur. Auparavant, j'avais tendance à aligner la recherche sur la même cadence que les sprints de développement, mais cela ne faisait que créer une pression inutile. Nous nous retrouvions parfois à la fin des sprints avec des recherches partielles, ce qui n'était pas efficace. Passer à une approche plus classique pour la recherche nous a simplifié la vie et nous a donné une meilleure visibilité sur nos activités. L'équipe de développement a également bien accueilli ce changement, car cela ne perturbe pas trop leurs habitudes de travail, et cela fonctionne donc plutôt bien pour eux. La seule difficulté que nous rencontrons, c'est que nous avons deux backlogs distincts : le backlog de découverte et le backlog de développement. Étant donné que nous travaillons en mode kanban d'un côté et en mode sprint de l'autre, il n'est pas toujours facile de les gérer dans le même outil. En terme d’outils nous utilisons principalement Google Sheet pour gérer le backlog de découverte, car c'est plus pratique que des outils traditionnels pour établir les priorités avec différents axes de travail. Pour les ateliers et la priorisation des différents types d'utilisateurs, nous utilisons Miro, car c'est l'outil déployé chez mon client. Ensuite, nous résumons les résultats dans Google Sheet pour suivre les étapes, déplacer les éléments dans nos backlogs, et réaliser le design. Pour le design, nous utilisons différentes méthodes en fonction des besoins, comme Figma pour les designs plus complexes, ou des Google Sheets ou Google Docs pour les éléments plus structurés, comme les formulaires. Parfois, nous créons également des prototypes pour les faire tester, mais dans le projet actuel sur lequel je travaille, ce n'est pas nécessaire. Pour vendre cette nouvelle approche, cela a été plutôt complexe et tendu. Le client est en pleine transformation et a mis en place un modèle hybride entre SAFe et le pseudo-modèle Spotify (“pseudo-” car ce modèle n’est pas réellement utilisé chez Spotify), avec des personnes ayant peu d'expérience en agilité, pensant peut-être que certifier les équipes à tout va suffisait à réaliser une transformation Agile... Cependant, ce modèle n'a pas été bien évalué, car ils n'ont même pas encore établi de retour d'expérience sur le MVP avant de le généraliser à d'autres équipes, ce qui est une première erreur. Pour donner un exemple concret de ce qui ne fonctionnait pas, sur un projet en particulier, le coach Agile qui nous accompagnait cherchait à nous imposer ce modèle, car c'était la consigne qu'il avait reçue, même si ce n'était pas du tout pertinent pour le produit sur lequel nous travaillions. Heureusement, avec l'aide de la Product Manager (PM) avec qui je travaille depuis presque un an, nous avons pu proposer une orientation différente pour les squads et la structure du projet : Étant donné que notre produit a des sous-produits avec des équipes techniques et métiers différentes, il était important d'avoir des Product Owners (PO) dédiés à chaque sous-produit, ainsi qu'un PO global pour la vision globale du produit. Nous avons donc dû sortir du modèle officiel qui nous était imposé, ce qui a généré quelques discussions sur le choix des termes, mais pour moi, le wording n'était pas un point crucial. De plus, étant donné que notre charge de travail allait évoluer au fil du temps, avec des petites et potentiellement grandes évolutions à gérer, nous avons mis en place un système évolutif avec une capacité à scaler facilement. Nous avons convenu qu'au début, nous aurions un Scrum Master commun pour gérer plusieurs squads À terme, si nous devions multiplier les squads, nous aurions besoin d'un Scrum Master dédié à chaque sous-produit, qui pourrait gérer plusieurs squads, dans une limite de trois maximum. Cela s'explique aussi par le constat que le rôle de Scrum Master n'est pas à temps plein, et qu'il peut être partagé entre plusieurs produits et squads. Cependant, gérer un écart important entre trois squads avec des équipes potentiellement différentes serait difficile à gérer en raison des différences de rythme, de fuseaux horaires et de rituels (notamment pour les daily.) D’où l’objectif de maintenir une cohérence au sein d'un même produit ou groupe de produits en impliquant les mêmes acteurs dédiés. Nous avons ainsi synchronisé les moments clés, tels que : La planification des sprints, en commençant par une planification globale avec le Product Owner (PO) global, puis en se divisant en planifications spécifiques à chaque sous-produit. De même, pour les rétrospectives, nous commençons par celles de chaque sous-produit avant de remonter au niveau global, afin de toujours garantir une vision transversale. Les daily stand-ups sont également synchronisées pour maintenir un rythme cohérent. De plus, si nous avons besoin de lancer des sous-projets, nous appliquons le même principe en adaptant l'échelle de manière appropriée et intelligente, en avançant avec un backlog commun qui se divise ensuite en sous-backlogs par sous-produit, avec une partie dédiée à la découverte et au développement. Nous avons imposé cette approche, en laissant les équipes discuter des détails de formulation. Au départ, elles étaient réticentes, mais nous avons expliqué que c'était ainsi que nous allions procéder en raison du contexte spécifique du produit. Pour résumer : Étant donné que les équipes n'étaient pas en mesure de nous proposer une organisation répondant à nos besoins, nous avons pris l'initiative de la créer. Cette organisation correspond à nos besoins actuels, mais nous sommes conscients qu'elle peut nécessiter des ajustements, que nous effectuerons en temps voulu. Nous avons déjà mis en place un modèle adaptable en fonction des KPI’s. Pour plus de rigueur, j'ai également effectué une recherche pour vérifier que cette approche n'était pas uniquement de mon invention, et j'ai trouvé des frameworks similaires, tels que LeSS et LeSS Huge qui correspondent à 95% à ce que nous avons proposé. Nous avons ainsi pu légitimer notre approche en nous appuyant sur ces références externes. En appliquant ces principes, nous avons un PO global et des area PO pour chaque zone et sous-produit, avec des domaines de besoins spécifiques. Cette approche a permis de faciliter l'adhésion des équipes à la stratégie. En effet, nous avions constaté que l es équipes partaient souvent trop rapidement dans la définition du produit sans prendre en compte la stratégie produit et la roadmap. Même si cela ne correspond pas entièrement à notre modèle actuel, nous estimons que c'est la meilleure approche pour notre équipe et cela nous permet de mieux remonter les besoins des utilisateurs. Il est également important de noter que les recherches que nous effectuons ne se limitent pas uniquement aux aspects digitaux. En effet, dans notre entreprise, nous ne demandons pas aux équipes de remonter les problèmes liés uniquement au digital. Même si certains aspects ne sont pas digitaux, il est important de les reconnaître, car ils peuvent être transmis aux équipes responsables des processus, des ressources humaines, des infrastructures, de la communication, etc. De ce fait, la phase de recherche, bien qu’officiellement liée à un produit, a une portée plus transverse et nous remontons régulièrement des sujets à d’autres équipes produits (ou même des équipes ne fonctionnant pas sur ce type de modèles). Notre objectif est de travailler de manière globale, holistique et systémique avec toutes les entités, sans se limiter à notre domaine digital. En effet, cette approche va à l'encontre des objectifs mêmes de la transformation.
