Le document présente le retour d'expérience de l'application de la méthode Scrumban pour améliorer un produit dans une entreprise de communication, après des échecs liés à l'externalisation et à une gestion de projet traditionnelle. L'adoption de Scrumban a permis d'augmenter la flexibilité, la qualité des livraisons et la satisfaction des clients, tout en facilitant l'adaptation aux changements de priorités. Les résultats incluent une meilleure prédictibilité des délais de livraison et une communication améliorée au sein de l'équipe.

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