Comment nous avons amélioré
notre produit avec ScrumBan
Retour d’expérience - Julien Rairat - 28 mai 2015
REMERCIEMENTS
À nos partenaires
MédiasFormation
À nos sponsors
Comment nous avons amélioré
notre produit avec ScrumBan
• Contexte
• Mise en place
• Apports
• Bilan
• Amélioration contin...
Contexte
Contexte
• Mon profil
• Salarié d’une grande entreprise
de la communication extérieure
• Ancien développeur J2EE, devenu
a...
Enjeux de la transformation
• Répondre aux demandes de nos clients: Directions
métiers France/international
• Améliorer la...
Le produit
• Produit existant et déjà en production avant le début du projet
• Développement réalisé à l'origine
au forfai...
Résultat
• Fonctionnalités répondant mal
aux besoins de nos utilisateurs
• Gros problèmes de qualité
et de performances
• ...
Mise en place
Mise en place du projet
1. Story mapping
2. Priorisation
MMF
Mise en place du projet
• 1. Story mapping: suite aux ateliers métier, catégorisation
des fonctionnalités en 4 catégories
...
• 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’i...
Premières semaines: mode Scrum pur
• Management visuel: suivi devs, obstacles (Kaizen), actions
• Tout afficher est très b...
Limites de Scrum
• 4 sprints après le début, constat d’une certaine rigidité
dans la notion de sprint
• Découverte des use...
Plus de sprint Daily meeting
Management visuel enrichi:
tableau PO + seuils
Planning poker au fil de l’eau
Point sur les i...
Bascule sur un mode « Scrumban »
• Plus de sprint: flux d'activité tiré
• Ecriture des stories par PO avec workflow: à écr...
Bascule sur un mode « Scrumban »
• Mise en place de KPI
• Débit de cartes/semaine, Cycle time, Lead time, taux de bugs…
• ...
Apports
Apports
• L’agilité: pourquoi ne l’a-t-on pas mise en place avant?
• Management visuel,
Daily meeting, Rétro:
comment fair...
• Suivi régulier et affichage des KPI:
• Possibilité d’agir dès que besoin (ex: indicateur
mauvais)
• Transparence: affich...
• Prédictibilité
• Capacité à estimer avec précision la date
de livraison d’une feature/d’une MMF,
basée sur la capacité r...
Bilan
Bilan
• Le passage en mode agile, avec accompagnement
coach, a été un changement du tout au tout:
• Qualité des livraisons...
Bilan
• Au fil des mois, le contexte projet a changé plusieurs fois
• Contraintes de délais, changement dans les priorités...
• Dans notre contexte projet, ScrumBan est un bon
compromis entre les bons côtés de Scrum et de Kanban
Bilan
• Scrum pur: ...
Amélioration continue
Amélioration continue
• Avec Scrumban nous sommes devenus prédictibles, mais
il a fallu nous adapter à notre contexte
• En...
• Affichage sur le tableau d’un « delivery dashboard »
• Tous les acteurs ont conscience de l’avancement de la version
• P...
• Actions concrètes suite aux rétros
• Pouce vert: décerné à une user story si tous les
tests d’acceptance passent du 1er ...
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
Comment nous avons amélioré notre produit avec ScrumBan
Prochain SlideShare
Chargement dans…5
×

Comment nous avons amélioré notre produit avec ScrumBan

5 302 vues

Publié le

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

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
5 302
Sur SlideShare
0
Issues des intégrations
0
Intégrations
226
Actions
Partages
0
Téléchargements
30
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 6’
    3 restants
  • 6’
    2 restants
  • 6’
    1 restant
  • 6’
    0 restant
  • 20’
    8 restants

  • 20’
    7 restants
  • 20‘
    6 restants
  • 20’
    5 restants
  • 20'
    4 restants
  • 20'
    3 restants
  • 20’
    2 restants
  • 20’
    1 restant
  • 20’
    0 restant
  • 26’
    2 restants

  • 26’
    1 restant
  • 26’
    0 restant
  • 32’
    2 restants
  • 32’
    1 restant
  • 32’
    0 restant
  • 38’
    2 restants
  • 38’
    1 restant
  • 38’
    0 restant
  • 41’
    3 restants
  • 41’
    2 restants
  • 41’
    1 restant
  • 41’
    0 restant
  • Comment nous avons amélioré notre produit avec ScrumBan

    1. 1. Comment nous avons amélioré notre produit avec ScrumBan Retour d’expérience - Julien Rairat - 28 mai 2015
    2. 2. REMERCIEMENTS À nos partenaires MédiasFormation À nos sponsors
    3. 3. Comment nous avons amélioré notre produit avec ScrumBan • Contexte • Mise en place • Apports • Bilan • Amélioration continue
    4. 4. Contexte
    5. 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. 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. 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. 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. 9. Mise en place
    10. 10. Mise en place du projet 1. Story mapping 2. Priorisation MMF
    11. 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. 12. • Equipe: • 1 PO + 1 analyste fonctionnel • 1 tech leader + 4 développeurs • 1 coach agile Mise en place du projet
    13. 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. 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. 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. 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. 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. 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. 19. Apports
    20. 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. 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. 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. 23. Bilan
    24. 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. 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. 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. 27. Amélioration continue
    28. 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. 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. 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. 31. Conclusion
    32. 32. Avant Scrumban • Ce que voulaient nos clients • Ce qui était spécifié
    33. 33. Avant Scrumban • Ce qui était livré, version après version
    34. 34. Après Scrumban • Ce que veulent nos clients • Ce qu’on leur promet • Le produit en démo
    35. 35. Après Scrumban • Après avoir vu la démo, ce que veulent finalement nos clients • Ce qu’on leur livre
    36. 36. Q/R

    ×