Retour d’expérience sur l’agilité et la méthode Scrum chez UFC Que Choisir et Voyages-sncf.com

Il est de plus en plus rare à ce jour d’entendre parler de projets digitaux sans que les mots “agilité” et “scrum” ne soient évoqués.

Pour aider des clients à sortir d’une impasse ou parce que ces méthodes sont déjà utilisées en interne, nombreux sont les consultants certifiés “scrum/agile” à intervenir dans des rôles de product owner, c’est-à-dire qu’ils définissent et priorisent, avec l’équipe métier et l’équipe de réalisation, le produit et ses fonctionnalités.

Avant de revenir sur deux cas concrets de “missions agiles”, voici quelques définitions.

Agilité et scrum en quelques mots :

• Faire de l’agilité c’est respecter le manifeste agile et ses 12 principes. C’est une façon de gérer les projets qui s’oppose généralement à la méthode traditionnelle (cycle en V).
• Scrum est un cadre de travail en méthode agile, qui propose un schéma d’organisation avec :
• Des rôles (le product owner qui recueille et priorise les demandes des parties prenantes, le scrum master qui est le chef d’orchestre et garant de la méthode) en savoir plus sur product manager vs. product owner
• Des réunions récurrentes (Sprint planning, rétro, démo, daily scrum),
• Des outils, appelés artefacts, qui facilitent l’exécution de la méthode (design thinking, product backlog, sprint backlog, cards ou user stories)
• Des règles (qui lient les rôles aux artefacts et aux réunions)

Ce cadre de travail s’inscrit dans un découpage temporel en sprint de 2 à 4 semaines.

Source : http://www.agiliste.fr/

Étude de cas n°1 : Scrum pour accompagner le projet de refonte du site internet UFC Que Choisir

Scrum est notamment adapté pour le développement de projets ou produits complexes. C’est tout naturellement que cette méthode a été proposée à UFC Que Choisir pour l’aider à concrétiser la refonte de son site internet en respectant des deadlines fortes fixées en interne. La méthode traditionnelle (cahier des charges, maquettes fonctionnelles, spécifications fonctionnelles générales et détaillées, maquettes graphiques) avait été utilisée dans un premier temps pour la partie front-office mais pas encore pour la partie back-office. Il y avait donc deux grands enjeux :

• Une liste de fonctionnalités front-office trop importante par rapport au temps imparti. Cette dernière présentait des éléments qui avaient été définis longtemps auparavant et plus nécessairement en phase avec les besoins métier.
• Aucune spécification pour la gestion en back-office et une ambition forte de changer de Content Management System (CMS) et de modifier l’architecture en place.

La mise en place de la méthode scrum a permis de gérer de manière efficace ces deux aspects, afin de livrer une première version dans les temps.

Scrum fonctionnant de manière empirique, le projet a débuté avec une première phase visant à définir l’architecture technico-fonctionnelle des back-offices ainsi que la technologie de CMS la plus adaptée aux besoins.

Ainsi, plutôt que d’attendre d’avoir défini de manière exhaustive l’ensemble des aspects d’un projet très complexe, via une approche ROIste et itérative, il a été possible de faire avancer le projet de manière très efficace, sans pour autant prendre de risques.

“L’approche itérative permet d’ajuster en continu. Tout n’est pas gravé dans le marbre, il est possible de changer et d’améliorer la commande.” estime Jean-Philippe. Machanovitch Directeur Marketing adjoint en charge du Web – UFC-Que Choisir

Un éléments clé de scrum réside dans la priorisation par le ROI de chaque élément fonctionnel (en langage scrum : card ou user story).

Comment définir le ROI de chaque card ?

Pour obtenir un ROI, deux éléments sont à définir pour chaque card : Sa complexité : c’est l’équipe de réalisation qui donne une valeur relative par rapport aux autres fonctionnalités. En tant que product owner, il est envisageable de négocier sur ce qui est inclut dans la fonctionnalité, voire la découper en plusieurs sous-fonctionnalités, pour séparer ce qui a le plus de valeur vs. ce qui est « nice to have ». Sa business value : estimée par les parties prenantes et les utilisateurs ; ayant parfois des intérêts divergents. Il peut donc être complexe de définir un dénominateur commun. C’est au product owner de les aider à le trouver.

• Méthodes d’estimation qualitatives : Organisation d’ateliers « buy your feature », où les parties prenantes vont définir le prix et acheter les user stories du futur produit, ou de façon relative, positionnement par rapport à d’autres user stories déjà évaluées.

• Méthodes d’estimation quantitatives : Utilisation des outils de webanalyse , d’A/B testing, ou de données métiers internes. Bien évidemment, dans le cadre d’un projet de refonte de site Internet, il est plus simple d’estimer la valeur pour une page ou une fonctionnalité existante  (à partir des données de webanalyse, nombre de pages vues, taux de clic, taux de conversion etc.) que pour une page ou une fonctionnalité nouvelle (une technique consiste à A/B tester un élément fonctionnel, comme un bouton, sans développer totalement la fonctionnalité, pour comprendre/estimer la performance de ce-dernier.)

Au fur et à mesure, le backlog (liste des cards ou user stories) va s’enrichir avec des valeurs, se préciser (division ou fusion de user stories) et s’ajuster en apprenant de ce qu’on a déjà fait. L’objectif n’est pas d’être précis dans les valeurs mais bien de pouvoir prioriser et d’obtenir le MVP (Minimum Viable Product : première version éligible à une mise en production).

Dans un projet, trois variables sont interdépendantes pour garantir la qualité du produit : le périmètre, le délai et les coûts. Si les 3 sont fixées indépendamment, il n’est pas possible d’en maîtriser la qualité. C’est souvent ce qui se passe en méthode traditionnelle, on fixe le périmètre (spécifications fonctionnelles générales puis détaillées), le planning et les coûts à priori. Lorsque les 3 variables ne sont pas en cohérence, c’est la qualité qui en pâtit.

Dans le cas de la refonte du site de l’UFC Que Choisir, la deadline était fixée pour la sortie du MVP, qui correspondait à une première version éligible à une migration, et un budget voté. Tout en gardant une petite marge de manœuvre sur les 2 premiers leviers, c’est le périmètre qui a été réduit pour respecter la deadline.

Après 10 sprints, les fonctionnalités développées étaient suffisantes pour faire la bascule des 2 principaux sous-domaines du site. Cette dernière a eu lieu le 1er juin 2016, pour une deadline fixée au 31 mai !

Après une phase de correction/stabilisation courant juin, les sprints ont repris avec des mises en production toutes les 3 semaines (à chaque fin de sprint). Les user stories du backlog (fonctionnalités et sous-domaines à migrer) seront priorisées selon leur ROI en fonction des premiers retours, des besoins métiers et des ambitions.

“L’attention de la DSI est plus portée sur la qualité du livrable que sur la deadline “  ajoute Jean-Philippe. Machanovitch Directeur Marketing adjoint en charge du Web – UFC-Que Choisir

Il faut savoir cependant, que passer “en méthode scrum” n’est en aucun cas une solution “miracle”, ni la garantie d’une réussite du projet ! En revanche c’est un cadre pour aider à :

• Tirer le meilleur parti des ressources
• Garantir la qualité des produits
• Commencer la phase de réalisation à partir d’une vision globale
• Travailler de manière itérative
• Eviter l’effet tunnel (période pendant laquelle les métiers n’ont pas de visibilité sur le produit)
• Ajuster la priorisation en fonction des feedbacks

Étude de cas n°2 : La méthode agile appliquée aux webanalytics chez voyages-sncf.com

La méthode agile peut s’appliquer à de nombreux processus différents, et pas seulement au développement pur de sites internet ou d’applications. Ainsi, l’équipe Webanalytics de Voyages-sncf.com travaille en méthode agile depuis un peu moins d’un an.

Elle a pour interlocuteurs différents clients internes, en charge des évolutions des pages du site ou du développement de nouvelles fonctionnalités. Leurs besoins métier en collecte de données sont centralisés par des product owners (PO) au sein de l’équipe Webanalytics, qui les traduisent en besoins de tracking du site. Ces demandes sont priorisées par les PO et leur complexité est évaluée par les développeurs de l’équipe. Ce travail préparatoire, orchestré lors de réunions récurrentes, permet de définir les sujets qui feront partie du “sprint”, c’est-à-dire qui seront traités dans les 3 semaines à venir.

Ainsi, le rendu final n’est pas un site ou une fonctionnalité du site, mais sa mesure, conformément aux spécificités livrées par les développeurs.

Quels sont les points positifs de cette méthode ?

• Réfléchir en amont aux sujets prioritaires à la différence de l’ancienne méthode, qui consistait davantage à du « premier arrivé-premier servi ».
• Chaque sujet est matérialisé par un post-it, et priorisé en le déplaçant sur un grand panneau : cela assure une transparence vis-à-vis des demandeurs et de l’équipe,  puisqu’il est possible de visualiser clairement les sujets par ordre de priorité.
• Une fois un sujet embarqué dans un sprint, un délai précis est communicable aux équipes métier quant à sa finalisation – qui aura lieu, si tout se passe bien, à la fin du sprint.
• Les équipes métier, clientes internes, qui sont également en méthode agile, reçoivent des spécifications techniques (« specs ») qu’elles peuvent implémenter rapidement. Cela leur permet de mesurer, par exemple, la performance d’un nouveau bouton, d’un nouveau volet qui se déplie. L’équipe analyse durant une période courte les données. En fonction des résultats, elle peut décider de garder ou non la fonctionnalité. Cette réactivité dans la prise de décision est possible grâce à la flexibilité de l’équipe Webanalytics.

Interview de Matthieu Ruault, responsable du pôle Méthodes et outils au sein de la direction Marketing Digitale de Voyages-sncf.com.

Pourquoi a-t-on fait le virage de l’agilité pour les webanalytics ?

Pour suivre le mouvement : tout le reste de l’IT se mettait à l’agilité, or l’agilité ne fonctionne que si toute la chaîne est agile. Si seulement un maillon est agile, l’ensemble de la chaîne n’est pas agile.

Après 1 an de mise en place, quel bilan en tirerais-tu ?

Le bilan est positif dans le sens où il y a un lien étroit entre les équipes techniques et métier, favorisé par la colocalisation (note : le fait que les product owners soient assis à côté des équipes de réalisation). Ces équipes partagent les mêmes méthodes de travail et la même vision : tout le monde y trouve son compte.

Quels sont les challenges de l’agilité pour l’équipe webanalytics ?

L’équipe webanalytics est une équipe transverse : la grosse difficulté est d’être suffisamment agile pour satisfaire les besoins en agilité des autres équipes. Il est donc primordial d’industrialiser un maximum de tâches pour gagner du temps ; c’est une des conséquences de l’agilité.

L’agilité n’est pas qu’un sujet IT, elle peut s’appliquer à tout produit. Et c’est un vrai changement dans les modes de travail, qui ne se fait pas en un claquement de doigt. En effet, il faut s’habituer à un mode de pensée, à des cérémonies très codifiées : il faut être accompagné, l’aspect conduite du changement n’est pas négligeable.

Les expertes: Capucine Levy, consultante senior chez Converteo, et Véronique Chupin, consultante senior chez Converteo.