Comment nous avons amélioré notre produit avec ScrumBan

Retour d’expérience - Julien Rairat - 28 mai 2015

REMERCIEMENTS

À nos partenairesMédiasFormation

À nos sponsors

Comment nous avons améliorénotre produit avec ScrumBan• Contexte• Mise en place• Apports• Bilan• Amélioration continue

Contexte

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

Mise en place du projet1. Story mapping

2. PriorisationMMF

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

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

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

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

Conclusion

Avant Scrumban

• Ce que voulaient nos clients

• Ce qui était spécifié

Avant Scrumban

• Ce qui était livré, version après version

Après Scrumban

• Ce que veulent nos clients

• Ce qu’on leur promet

• Le produit en démo

Après Scrumban

• Après avoir vu la démo, ce que veulent finalement nos clients

• Ce qu’on leur livre

Q/R