Retour d'expérience sur la mise en place de Scrumban Présentation effectuée le 28/05/2015 au Kanban Day

1. Comment nous avons amélioré
notre produit avec ScrumBan
Retour d’expérience - Julien Rairat - 28 mai 2015

2. REMERCIEMENTS
À nos partenaires
MédiasFormation
À nos sponsors

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

4. Contexte

5. 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

6. 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)

7. Le produit
• Produit existant et déjà en production avant le début du projet
• Développement réalisé à l'origine
au forfait, dans un centre de services
en 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?)

8. Résultat
• Fonctionnalités répondant mal
aux 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

9. Mise en place

10. Mise en place du projet
1. Story mapping
2. Priorisation
MMF

11. 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

12. • Equipe:
• 1 PO + 1 analyste fonctionnel
• 1 tech leader + 4 développeurs
• 1 coach agile
Mise en place du projet

13. 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

14. 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 a
aimé/pas aimé/propose des
actions
• Discussion constructive

15. 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

16. Plus de sprint Daily meeting
Management visuel enrichi:
tableau PO + seuils
Planning poker au fil de l’eau
Point sur les indicateurs +
rétrospective toutes les 2
semaines
Démos toutes les 2 semaines
avec nos key users
Bascule sur un mode « Scrumban »

17. 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…)

18. 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:

19. Apports

20. 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

21. • 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é ++

22. • 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

23. Bilan

24. 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

25. 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

26. • 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

27. Amélioration continue

28. 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

29. • 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

30. • 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

31. Conclusion

32. Avant Scrumban
• Ce que voulaient nos clients
• Ce qui était spécifié

33. Avant Scrumban
• Ce qui était livré, version après version

34. Après Scrumban
• Ce que veulent nos clients
• Ce qu’on leur promet
• Le produit en démo

35. Après Scrumban
• Après avoir vu la démo,
ce que veulent
finalement nos clients
• Ce qu’on leur livre

36. Q/R