Vous repartirez avec

• Un retour d'expérience sur un changement organisationnel dans un contexte de delivery intense
• Les leçons tirées de ce changement
• Notre ressenti de Product Owner / Technical Leader

Lesfurets.com, qui sommes nous ?

• Comparateur d'assurance
• 3 millions de devis par an
• 40 à 200 questions par tunnel

Le delivery chez lesfurets.com

• 7 Experts Métier, 23 développeurs
• 3 Feature Teams (SEO, Conversion, Infrastructure)
• 1 base de code de 500.000 lignes
• 1 à 3 release par jour
• 20/30 branches Git en parallèle

Le delivery chez lesfurets.com

• 2012 : Spring Scrum mensuel
  12 releases (build 15 minutes et selenium 1 heure)


• 2013 : Sprint scrum hebdo
  45 releases (build 3 minutes, release 1 jour)


• 2014 - 2016 : Flux Kanban livraison quotidienne
  208, 217, 220+ releases (release 2 heures)


• 2017+ : Release partielle, release par feature

La demande

• Fusion des équipes
• Autour des problématiques globales de conversion

Perception de l'équipe

Etonnement : Fusion est forcée

Spécialisation toujours présente : tunnel vs partenaire

Perception du management

Ca n'avance pas assez vite !

Perception de l'équipe

Equipe trop grande

Manque de clarté sur les priorités

Perception du management

Vu la taille de l'équipe, pourquoi ne peut-elle pas développer plus de user stories ?

Perception de l'équipe

Plus de sens

L'équipe s'améliore

Organisation plus fluide

Perception du management

Ne touchons plus à l'équipe !

Comment ça s'est passé pour l'équipe

• Envie de découvrir et d'apprendre de nouveaux sujets
• Peur du changement, mais on y gagne peut être quelques choses
• Savoir comment mieux faire après

Bénéfices

• Objectif commun
• Visibilité
• Partage de connaissance

Ce qui a bien marché

• Laisser mûrir les problèmes
• Engagement fort lors des rétrospectives
• Mise en place progressive
• Amélioration continue
• PO et TL en posture de Servant Leadership

La rétrospective

• Revue des actions
• Expression libre et team-mood
• Débat ouvert sur 2/3 gros sujets
• Plan d'actions réaliste, obligatoirement un porteur d'action
• Equipe plus heureuse si elle améliore sa situation tous les jours

Ce qui n’a pas marché

• Plaquer des solutions sans avoir cerné le problème
• Equipe trop grande : plus de coordination
• Pas de formation pour passer du back au front
• Delivery tendu sur tous les sujets, pas assez de binômage et de partage

Ce qui aurait pu être fait différement

• Etudier le mode de fonctionnement de chaque équipe avant de les rassembler en une seule
• Plus de communiquation du management vers la future équipe
• Limiter la taille de l'équipe
• Se réorganiser régulièrement par petit projet pour être plus souple

Product Owner

• Priorisation macro et micro de l’encours
• Arbitrer asap les sujets qui bloquent ou freinent l’équipe
• Ecouter et relayer les problématiques techniques
• Ecouter et relayer les idées produit
• Protéger l’équipe du “bruit” extérieur.

Tech Lead

• Protection de l'équipe du "bruit" extérieur
• Etre disponible le plus possible en cas de demande d'aide
• Balance entre les tâches de développement et de coordination
• Se réserver impérativement du temps pour développer
• N'attaquer qu'un seul gros sujet technique de fond à la fois

Wrap up

Bien identifier et communiquer les problèmes à solutionner

La rétrospective est primordiale pour Kanban et Continuous Delivery

Garder du temps en plus pour l'apprentissage