Comment nous avons amélioré notre produit avec ScrumBan
Retour d’expérience - Julien Rairat - 28 mai 2015
Comment nous avons améliorénotre produit avec ScrumBan• Contexte• Mise en place• Apports• Bilan• Amélioration continue
Contexte
• Mon profil• Salarié d’une grande entreprise
de la communication extérieure• Ancien développeur J2EE, devenu
analyste fonctionnel puis Product Owner
• Contexte• Echec de l’externalisation des développements de nos
produits• En 2014, lancement de la transformation agile de la DSI
Enjeux de la transformation
• Répondre aux demandes de nos clients: Directions métiers France/international
• Améliorer la qualité de nos produits
• Réduire le Time To Market (délai entre l’émission d’une demande et sa mise en production)
Le produit
• Produit existant et déjà en production avant le début du projet
• Développement réalisé à l'origineau forfait, dans un centre de servicesen France, « à l'ancienne »
• Qualité des livraisons très aléatoire et très faible flexibilité• Besoin de specs parfaites à la virgule près• Négociation nécessaire au moindre point litigieux (bug ou évol?)
Résultat
• Fonctionnalités répondant malaux besoins de nos utilisateurs
• Gros problèmes de qualitéet de performances
• Dette technique en augmentation permanente
• En mars 2014, lancement d’un projet d’amélioration du produit en mode agile, « pilote » de la transformation agile de la DSI
Mise en place du projet
• 1. Story mapping: suite aux ateliers métier, catégorisation des fonctionnalités en 4 catégories
• Nouvelle/Existante à conserver/à modifier/à supprimer
• 2. Priorisation par MMF (Minimum Marketable Feature)
• MMF = Ensemble cohérent de fonctionnalités pouvant être livrées en production, utilisables et ayant une valeur métier
• MMF1: fonctionnalités à forte valeur métier, pouvant être mise en production rapidement + quick win
• Priorités: TTM + gain de confiance rapide utilisateurs
• Equipe:• 1 PO + 1 analyste fonctionnel• 1 tech leader + 4 développeurs• 1 coach agile
Mise en place du projet
Premières semaines: mode Scrum pur
Sprints de 2 semaines Daily meeting Management visuel
Planning poker à chaque début d’itération
Rétrospective à chaque fin d’itération
Démos toutes les 2 semaines avec nos key users
Premières semaines: mode Scrum pur• Management visuel: suivi devs, obstacles (Kaizen),
actions• Tout afficher est très bénéfique
• Rétrospective:• Chaque membre de l’équipe
écrit sur des Post’it ce qu’il aaimé/pas aimé/propose desactions
• Discussion constructive
Limites de Scrum
• 4 sprints après le début, constat d’une certaine rigidité dans la notion de sprint
• Découverte des user stories par l’équipe technique lors du planning poker à chaque début de sprint
• Long cérémonial• Difficulté d’estimer la complexité d’une story de but en blanc,
sans avoir pu analyser un minimum les impacts
Plus de sprint Daily meetingManagement visuel enrichi:
tableau PO + seuils
Planning poker au fil de l’eau
Point sur les indicateurs + rétrospective toutes les 2
semainesDémos toutes les 2 semaines
avec nos key users
Bascule sur un mode « Scrumban »
Bascule sur un mode « Scrumban »
• Plus de sprint: flux d'activité tiré• Ecriture des stories par PO avec workflow: à écrire, en cours,
prêt à estimer • Lorsque nécessaire, l’équipe technique « tire » les stories et
les estime au fil de l'eau
• Définition de seuils par colonne: nb min/max de cartes• Evite les goulets d’étranglement: sur quoi dois-je travailler en
priorité? (écrire story, tester, estimer…)
Bascule sur un mode « Scrumban »
• Mise en place de KPI• Débit de cartes/semaine, Cycle time, Lead time, taux de
bugs…• Suivi régulier des indicateurs (toutes les semaines au
minimum)• Cadencement: toutes les 2 semaines, présentation à la rétro• Affichage sur les tableaux:
Apports
• L’agilité: pourquoi ne l’a-t-on pas mise en place avant?
• Management visuel,Daily meeting, Rétro:comment faire sans?
• Traitement des obstacles par cérémonies Kata
• Suivi régulier et affichage des KPI:• Possibilité d’agir dès que besoin (ex: indicateur
mauvais)• Transparence: affichage à la vue de tous
Apports
• Scrumban: plus grande souplesse• Seuils bien réglés = pas de temps d’attente• Limitation du WIP (Work in Progress) à la capacité à faire de
l’équipe• Estimation stories au fil de l’eau: efficacité ++
• Prédictibilité• Capacité à estimer avec précision la date
de livraison d’une feature/d’une MMF, basée sur la capacité réelle de l’équipe
Apports
• Méthode utilisée: macro-estimation feature en nombre de cartes + ajout d’une marge (stories techniques, bugs, prise en compte feedback…)
• Permet d’être en phase avec le TTM
Bilan
• Le passage en mode agile, avec accompagnement coach, a été un changement du tout au tout:
• Qualité des livraisons en nette hausse
• Satisfaction de nos clients
• Réactivité, prise en compte du feedback
• Communication et ambiance dans l'équipe
Bilan
• Au fil des mois, le contexte projet a changé plusieurs fois
• Contraintes de délais, changement dans les priorités• Nous avons à chaque fois su nous adapter et répondre
présents
• Dans notre contexte projet, ScrumBan est un bon compromis entre les bons côtés de Scrum et de Kanban
Bilan
• Scrum pur: rigidité des sprints
• Kanban pur: manque de notion d’engagement de l’équipe sur des délais de livraison
Amélioration continue
• Avec Scrumban nous sommes devenus prédictibles, mais il a fallu nous adapter à notre contexte
• Engagements forts de dates de livraison/périmètre précis
• Manque de visibilité sur la réalisation de la version (effet tunnel de plusieurs semaines)
• Conséquence: manque d’engagement/ responsabilité de l’équipe
• Affichage sur le tableau d’un « delivery dashboard »
• Tous les acteurs ont conscience de l’avancement de la version • Possibilité de déprioriser certaines user stories en cas de retard
Amélioration continue
Dates clés
Avancement de la version en cours:- Date de livraison- Nb cartes Done
- Nb cartes prévues
Burndown chart (notion Scrum)
Permet de savoir d’un coup d’œil si on
est en retard
• Actions concrètes suite aux rétros• Pouce vert: décerné à une user story si tous les
tests d’acceptance passent du 1er coup
• Nouveaux types de cartes: support, User story « pair testing demandé »
Amélioration continue
Après Scrumban
• Après avoir vu la démo, ce que veulent finalement nos clients
• Ce qu’on leur livre