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