Comment nous avons amélioré notre produit avec ScrumBan

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

1 commentaire
1 j’aime
Statistiques
Remarques
  • Merci Julien pour le partage de ton expérience, j'étais assez critique face à Scrum et intéressé par Kanban et c'est pas hasard que j'ai découvert ScrumBan. Je vois que cette méthode répond aux besoins des différentes équipes. Je vais m'orienter vers cette solution prochainement, en espérant avoir la même réussite que toi !
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
5 360
Sur SlideShare
0
Issues des intégrations
0
Intégrations
226
Actions
Partages
0
Téléchargements
31
Commentaires
1
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

    ×