SNCF Connect: l’exemple à ne pas suivre

Principe Agile du mois d’Octobre

https://agilemanifesto.org/iso/fr/principles.html

“Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.”

Pierre:

  • De facon passive, pas pro-active.

Julien:

  • Oui, mais non. Je me bats contre trop de changement pendant le dev.

SNCF Connect

App la plus utilisée en France

Lancé en Jan 2022 (Anciennement OUI SNCF)

Devait faciliter la vie des usagers, mais tellement buggée qu’elle a été immédiatement détestée.

Résultat

Beaucoup de bugs ont été fixés depuis MAIS beaucoup de fonctionnalités de base ne sont toujours pas présentes:

  • On peut faire un arrêt sur les long trajets, mais pas plus (ce qui n’était pas le cas dans l’ancienne appli)
  • Aberration dans la barre de recherche: la destination est en premier! (UX)

Phase de test

Plus d’un an de dev, le beta test a commencé 2 mois avant le lancement.

  • Les tests ont débuté très tard (Novembre) — vacances de Noel, aucun beta testeur n’était focus sur l’application.Très peu de retours
    Plusieurs milliers de personnes.
    Panel: tech-savvy non représentatifs de l’utilisateur moyen.
  • SNCF voulait la plus grande confidentialité autour de l’application durant les phases de développement.

Fonctionnalités

Exemple de fonctionnalité manquante:

  • ajouter le billet dans le wallet Apple/Google
  • absence de filtres pour les trajets

→ Regression par rapport à OUI SNCF

Step back

Pourquoi avoir lancé le dev d’une nouvelle app? Arrivée d’un nouveau dirigeant.

Comment: débauché quelques personnes d’Accenture pour tout dev en interne, encore pour une raison de confidentialité…

Approche non itérative assumée:

  • Approche Big Bang.
  • Aucune gestion du changement pour les utilisateurs: juste lancé une mise à jour Majeure sur les téléphones (l’ancienne appli a été remplacée du jour au lendemain par la nouvelle).
  • Aucune modularité.
  • → probablement dans une volonté de booster l’adoption. Si on remplace, personne ne pourra rester sur l’ancienne appli, donc la nouvelle ne peut pas être un échec.

Too many cooks in the kitchen? On pense que ça va être compliqué, donc on monte une grosse équipe (plusieurs centaines de gens).

Pas d’objectif clair, vision non communiquée.

Problématiques actuelles

Pierre:

  • Nouveau quarter, nouveaux problemes = 1 gros projet (money maker) d’une squad dripping dans les autres - manque de logique dans le split des Key Results
  • Etre de plus en plus EM > TL - mais dur a realiser avec une team qui n’est pas encore autonome = mise en place de petits processes (DoD, DoR, captain) pour aider l’equipe a maturer

Julien:

  • Beaucoup de choses qui se passent en perso, ça fait relativiser le pro.
  • Prise de recul.

Outils de l’épisode

Julien:

  • Le livre de Pierre-Henri Chuet, dit “Até”: Au-delà du cockpit (Chef de patrouille dans la Marine)


Les méthodes agiles hors de la tech