Talk de Ludovic Perot, Directeur de Xebia Studio.

Abstract

En Janvier 2017, Europ Assistance lance un projet ambitieux : refondre et unifier les SIs qui gèrent près de 5 millions d’interventions de dépannage à travers le monde. C’est l’histoire d’une transition qui s’effectue : on délivre un produit, et non plus un projet, en itérations courtes, et non pas en bloc de deux ans. Cette présentation est un retour sur les difficultés et succès vécus quand on remplace plusieurs legacies par un MVP…

Notes

REX Europe Assistance / Thiga (Boite de Product manager dans Xebia) / Xebia

Contexte

• 300 M de clients
• 10M interventions
• Clients : B2C / assureurs

Appel d’offre agile

• Changement d’un legacy
• MVP en 1 + 5 sprints
• Besoin fonctionnel
• Petite équipe de 7 personnes

Extreme archi

• Définir l’archi cible très vite
• Table ronde pendant 3 jours entre toutes les parties prenantes

Première road map

• Ateliers de 1 semaines
• Story mapping
• Comprendre les étapes clé de l’expérience user
• établir le première fonctionnel du MVP
• Créer un parcours assistance end-to-end
• Définir la vélocité
• Magic estimation (192 stories) : Permet de donner un ordre de délai au client

Il ne faut pas s’engager à des prédictions de long termes

Double diamant : design thinking

• Phase exploratoire : s’associer avec les opérateurs
• Phase Define : avec les stack holders / définir les ébauches des US
• Phase Ideate
• Phase expertement : Livraison avec des min de feature / pas de dépendances en prototype

Attention : ne pas le faire trop en interne

V2

• plus de complexité fonctionnelle
• Rythme de dev
• Cycle de design

Erreurs :

• Passage de 2 PO à un PO
• Plus de DEV —> Cadence accélère
• S’éloigner des opérateurs / métier
• Vision très simple du métier
• On repousse les décisions difficiles parce qu’on a le nez dans le guidon :

  Attention : focus delivery

Retour V0 = MVP

• Essayer de résoudre les problèmes
• Le PO écrit des US pour les DEV
• Problèmes fonctionnels clés non résolus

—> Reprise de la récolte de besoin

Outils : burn down

Maximum Viable Product

• Construire un outil sur 3 outils existants (20 ans ancienneté)

V0 en marche vers la prod

• Montée à 10 DEV
• Conserver l’efficacité
• 2 FT
• Conserver un esprit one team
  • Même open space
  • Retro et demo commune
• Comment découper le backlog
  • Par thème
  • Par Epic
• Split daily planning
• Supporter les rotations
• Suivi des notes de satisfactions
• Agilité : Cadre pour protéger le craftsmanship

La Motivation

Actions

• Arrêter le dev fonctionnel pour les dev techniques sur 2 sprints
• Mettre en beta testing
• Une partie des opérateurs vont utiliser l’outil en prod
  • Permet de remonter les bugs
  • Avoir un feedback

Les défis

• Produit
  • Couvrir l’intégralité du périmètre opérationnel
  • Déployer la solution sur les filiales du groupe
• Niveau groupe
  • Transition agile
  • Maintenir vision produit