Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

Le cadre de travail qu’offrent les méthodes agiles, et particulièrement Scrum, est parfaitement adapté aux petites équipes. L’équipe produit gère son Product Backlog, artefact n°1 du Scrum. Cet outil, qui liste les fonctionnalités à implémenter, est flexible, transparent et activable. Il décuple la création de valeur. Ainsi, ce cadre leur permet de produire de la valeur en continu, tout en maîtrisant les risques.

À l’échelle, plusieurs équipes gèrent leur Product Backlog en parallèle. Leur incrément alimentant un produit commun, la coordination est essentielle : à la fois sur le “quoi” - quelles fonctionnalités les équipes vont livrer - et sur le “comment” - comment ces fonctionnalités sont livrées le plus régulièrement possible. Explorons cela ensemble.

Aligner les feuilles de route...

D’expérience, nous observons un désalignement des roadmaps produit une fois l’organisation passée à l’échelle. Chaque Product Owner travaille sur sa roadmap et donc sur son propre Product Backlog. Le problème : ce backlog ne reflète pas forcément la vision qui a été définie en fonction des priorités business et des besoins utilisateurs. Nous l’avons rencontré lors d’un projet mené avec l’un de nos clients, l’absence de vision partagée a poussé chaque Product Owner à définir ses propres priorités. L’impact de cette absence de cap et d’informations est direct : les équipes perdent progressivement leur motivation, sous-performent et la valeur délivrée aux utilisateurs n’est pas maximisée.

Pour y remédier, nous recommandons la mise en place d’un cycle de coordination entre les Product Owners (NB : appelé MetaScrum dans le framework Scrum@Scale). Concrètement, cela passe par la nomination d’un rôle de Chief Product Owner, chargé de générer un macro Product Backlog priorisé par la valeur, contenant des user stories découlant de la vision commune. Ces user stories étant ensuite déversées et affinées dans les Product Backlogs de chaque équipe. Un rituel hebdomadaire de synchronisation de cette équipe de Product Owners devient l’occasion de partager aux Products Owners les priorités de ce macro Product Backlog.

...et les cycles d’itération de chaque équipe...

Le cadre Scrum garantit l’itération à travers les rituels. Pour rappel, il en existe cinq : le Sprint Planning, le Daily Scrum, la_ Sprint Review_, la Sprint Retrospective et le Sprint. Ces rituels sont l’occasion pour l’équipe d’inspecter et d’adapter leur travail. Ils lui permettent de livrer en continu de la valeur avec un time-to-market réduit, évitant le fameux “effet-tunnel” que l’on observe dans l’utilisation de méthodes de développement plus classiques.

Connexions auprès de partenaires externes, rythme de développement différent entre deux équipes… à l’échelle, les dépendances entre les équipes sont nombreuses. La communication est alors essentielle pour assurer la bonne synchronisation des équipes.

Nous parlions de l’optimisation du what ci-dessus, il s’agit maintenant de se concentrer sur le how : comment délivrer un maximum de valeur le plus régulièrement possible. Parallèlement au cycle de coordination des Product Owners, nous recommandons la mise en place d’un cycle de coordination entre Scrum Masters (NB : appelé Scrum of Scrums dans le Scrum@Scale).

Concrètement, l’idée est de débarrasser les équipes des goulots d’étranglement et des blocages. En Daily Scrum - et aussi en Sprint Retrospective - l’équipe inspecte son travail et s’adapte en cas de blocages en définissant des actions pour les résoudre. Si la résolution est indépendante de l’équipe, le Scrum Master remonte le point en Scaled Daily Scrum auprès des autres Scrum Masters. Lors de ce rituel, chaque Scrum Master répond aux questions suivantes :

• quels obstacles mon équipe rencontre-t-elle, l’empêchant d’atteindre son objectif ?
• quels comportements mon équipe adopte-t-elle, empêchant une autre équipe d’atteindre son objectif ?
• de nouvelles dépendances entre les équipes ont-elles été découvertes ou résolues ?

L’équipe de Scrum Masters nourrit alors son propre Transformation Backlog des actions décidées ensemble pour résoudre les blocages avec un responsable et une deadline.

La bonne synchronisation des équipes et des rituels prend tout son sens lorsqu’il s’agit de partager l’atterrissage du produit : à quelle échéance atteint-on le périmètre visé ? quel périmètre viser compte-tenu de notre échéance ? Maîtriser son atterrissage devient plus complexe à mesure que les dépendances entre les équipes augmentent. Dans ce contexte, il est donc essentiel de rendre transparent son atterrissage auprès des autres équipes sur la base de l’empirisme. Cela permet à chaque équipe de respecter le périmètre visé. Nous le disons souvent : l’agilité n’est pas une recette miracle mais un moyen de rendre visible plus rapidement les problèmes pour trouver des solutions (inspection et adaptation).

Vos équipes ont un time-to-market et un périmètre fixés ? Ajustez ponctuellement la capacité de production et donc les ressources pour délivrer un maximum de valeur.

...tout en conservant leur autonomie pour déployer en continu

La livraison en continu des évolutions que vous apportez à votre produit - ce qu’on appelle l’intégration continue - est votre dernier défi dans l’optimisation de votre exécution. Suite au lancement de votre MVP, vous allez constamment le modifier pour trouver votre Product Market Fit : l’adéquation de votre produit avec son marché.

Cela passe par l’adoption des standards DevOps : automatiser l’ensemble des tâches manuelles récurrentes sur lesquelles le développeur n’a pas de valeur ajoutée, de la création d’une application à son exploitation. Cela concerne par exemple les déploiements ou l’exécution de tests automatisés.

Avec la croissance et le passage à l’échelle, l’enjeu n’est plus tant d’aligner votre time-to-release à votre rythme d’itération qu’au niveau d’exigence de vos clients. À titre d’exemple, on compte en milliers le nombre de déploiements par jour d’un Amazon ou d’un Netflix, c’est même un déploiement en moyenne toutes les 11,6 secondes pour Amazon !

Pour y parvenir, il vous faudra relever deux challenges.

En premier lieu, chaque équipe doit conserver son autonomie d’intégration continue. En d’autres mots, elle ne peut pas se permettre d’attendre que les autres équipes soient prêtes à livrer pour elle-même livrer son incrément aux utilisateurs. Pour les plus techniciens d’entre vous, cela passe encore par une hausse significative des standards DevOps : déploiements automatisés lors du merge de pull requests et roll-back automatique en cas d’erreur par exemple.

Ensuite, l’infrastructure doit supporter un trafic plus dense. Cela passe par une hausse des standards d’infrastructure : monitoring des serveurs, analyse des logs… C’est par exemple prévoir l’augmentation automatique de la disponibilité des serveurs lors d’un pic de trafic dû à un spot TV.

En conservant cette autonomie vis-à-vis des utilisateurs, vous avez les moyens de vous adapter et de répondre rapidement aux besoins de vos utilisateurs. Autrement dit, vous avez les moyens de maintenir votre Product Market Fit, l’adéquation de votre produit avec votre marché.

Comment faire pour le maintenir ? Ce sera justement le sujet de notre prochain article.