Avant la session …  Avez-vous un point d’insatisfaction dans votre  expérience de la méthode Scrum ?  Si oui, notez le sur...
Scrum à Kanban:3 retours d’expériences Elise Vanholsbeeck / Véronique Mosnier / Nicolas Warzagier / 8 Novembre 2012
Qui sommes-nous?  Véronique    Elise    Nicolas   Travel     Backend   Shopping
Qui êtes-vous?
AgendaRappelsRetours d’expériences  Qui?  Pourquoi?  Comment?  Quoi?  Et maintenant?Bilan général
AgendaRappelsRetours d’expériences  Qui?  Pourquoi?  Comment?  Quoi?  Et maintenant?Bilan général
Rappels sur ScrumRappels
Rappels sur Kanban                     WIP          Flux
Historique des méthodes dedéveloppement chez kelkoo    Cycle en V        Scrum          Kanban               2007         ...
AgendaRappelsRetours d’expériences  Qui?  Pourquoi?  Comment?  Quoi?  Et maintenant?Bilan général
3 équipes – 3 profils                               Travel                Backend           ShoppingEffectif              ...
AgendaRappelsRetours d’expériences  Qui?  Pourquoi?  Comment?  Quoi?  Et maintenant?Bilan général
Les raisons du changementQuels sont les points d’insatisfaction rencontrés avecla méthode Scrum?                          ...
AgendaRappelsRetours d’expériences  Qui?  Pourquoi?  Comment?  Quoi?  Et maintenant?Bilan général
La transition                     Travel                Backend                    ShoppingMotivation    Toute l’équipe   ...
AgendaRappelsRetours d’expériences  Qui?  Pourquoi?  Comment?  Quoi?  Et maintenant?Bilan général
Kanban Travel
Kanban Backend   Definition of Done    Definition of Done   de chaque colonne     de chaque colonne      WIP              ...
Kanban Shopping           Une colonne                   Une colonne          « pense-bête »                 surchargée !  ...
Cérémonies d’équipes                   Travel     Backend           ShoppingStand-upDemoRetroPoker planningScenarii /Backl...
AgendaRappelsRetours d’expériences  Qui?  Pourquoi?  Comment?  Quoi?  Et maintenant?Bilan général
Conclusion Travel    Visualisation du flux    Capacité à faire de la QA    Incapacité à évaluer les tâches avant
Conclusion Backend    Sortir de la routine    Productivité identique    Métriques mal exploitées
Conclusion Shopping    Intégration des imprévus au flux    Flux formalisé et évolutif    Mauvais usage du WIP
AgendaRappelsRetours d’expériences  Qui?  Pourquoi?  Comment?  Quoi?  Et maintenant?Bilan général
Avantages• Visualisation   Étapes de développement   Bloqueurs   Spécialisations• Souplesse   Gestion de la priorisati...
Inconvénients• Organisation à la demande   Travail constant du PO et du Scrum Master   Mauvaise compréhension des Storie...
Ce qui ne change pas• Les rôles et le Product Backlog• La productivité    Temps de développement équivalent    Temps tot...
Référence                          Disponible gratuitement                          http://www.infoq.com/minibooks/kanban-...
L’essentielFormaliser le flux et limiter le WIPConserver les bonnes pratiques de ScrumPas de recette miracle – chacun i...
Prochain SlideShare
Chargement dans…5
×

Agile grenoble 2012scrum_kanban on_live_agile_grenoble

523 vues

Publié le

Agile Grenoble 2012: Scrum a Kanban 3 retours d'experiences

Publié dans : Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
523
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
10
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • L’objectif de cette présentation est de vous donner un retour d’expérience sur la manière dont 3 équipes de Kelkoo sont passés de Scrum à Kanban.Contrat-Est-ce que je dois faire du Kanban avec mon equipe?Comment faire pour passer de Scrum à Kanban?Quelles sont les bonnes pratiques que je pourrais implémenter chez moi?Ce que vous ne verrez pas-la théorie Kanban & la théorie Scrum
  • Qui sommes nous-Véronique: SM travel – SM shopping – 10 ans de conseil & de facilitation chez Capgemini – SM Yahoo – SM kelkoo-Elise: Scrum master. Je travaille chez kelkoo depuis 8 ans et demi. J’ai commencé en tant que développeur. Mon équipe a adopté Scrum il y a 5 ans. Je travaille en kanban depuis 6 mois avec l’équipe Backend.-Nicolas: Dev Shopping -- Développeur au sein de l'équipe frontend depuis Mars 2011, Nicolas s'est initié aux méthodes Scrum & Kanban dans un environnement Agile en constante évolution. 
  • Qui êtes vous (Faire monter la main a tout le monde)-Qui pratique / a déjà pratiqué Kanban?-Qui pratique / a déjà pratiqué Scrum?
  • Scrum: 9 prescriptions: 3 roles (SM – PO - Team) 3 artifacts (PB – SB – Burndown chart) 3 ceremonies (Stand up, Demo–retro, Sprint planning)Impediments: imprevus a gerer pendant le sprint
  • VeroKanban: 3 prescriptions visualisezvotre flux, limitezvotre WIP, mesurez et optimisezvotre temps de cycleLe but estque tout le monde se mobilise pour faire sortirunetache le plus rapidement possible du kanban – quetoutes les taches ne restent pas dans le kanbanFLUX: cesont les differentesetapes par lesquellesles tachesdoivent passer pour atteindre la definition du DONEWIP: work in progress: on ne peut pas avoir plus de n tachesdansuneetapes du fluxEn scrum les tachespeuventetrefaites à leurrythme du moment qu’ellessont la a temps pour la demoLes points communs: Les 2 sontempiriques les 2 sont un flux tireLimitation du le flux= S : par iteration, K par le WIPAuto-organisation des équipesUtilisation du management visuelAmélioration continueDécoupage du travail en petite tâche
  • Elise Les méthodologies de développement ont changé avec le temps chez Kelkoo. Alexandre Boutin a été impliqué dans l’implémentation de chacune de ces méthodologies chez Kelkoo : cycle en V, Scrum et KanbanPour l’anecdote, c’est lui qui en 2006 a formalisé un process assez lourd sur le cycle en VCe process a néanmoins permis de faire collaborer les différentes de dev, test et prod ensemble.En effet entre chaque étape, un comité était réuni pour savoir si l’on pouvait passer à l’étape d’après comme du dev au test.Chacune des équipes avait ainsi son mot à dire aux différentes étapes.2007 Une méthodologie Agile : SCRUM Les dev, testeur et personnes de la prod se regroupent pour former des équipesScrum et ainsi les projetsmigrent petit à petit à scrum.2011 Une équipe décide de passer en Kanban. Quelques mois plus tard, 2 autres équipes passent en Kanban.Aujourd’hui, nous avons 4 équipes en Scrum, 3 enKanban.
  • Backend-EliseAvant le passage à KanbanMulti-compétences, pas de spécialiste dans l’équipeMaintenance : Petites évolutions, maintient essentiellement une bonne stabilité et bonne performance de la plateforme.Peu d’exposition business, la plateforme n’est pas utilisée directement par l’utilisateur. Les impacts sur Kelkoo sont moins immédiats que le Frontend.Très bonne maitrise de scrum, bonne expérience de toute l’équipe.Nico1 dev / 1 archi / 1 QA / 1 SM non dedieSite web en mode Maintenance : site refondu il y a un an et demi – demande de bug fix – de petites evolutions – projet stabiliséAttentes métiers fortes: premiere ligne – partie emergée de l’iceberg – grande réactivité sur des demandes de pub
  • Raisons travelEquipe distribuée – besoin de visibilité sur le travail de chacunTrops d’instabilites en prod qui generaient beaucoup d’impedimentsImpossible de mettre de la QA sur le projetRaisons backend :Sortir de la routineEssayer d’améliorer la productivitéRemotiver/ redynamiser (après perte du scrum master)Raisons shopping:Besoin de formalisation du flux – différence de définition du done ; non-conformité au DONETrop de temps passé en cérémonialsEquipe distribuée – besoin de visibilitée sur le travail de chacunContrat de sprint non tenu a cause des impediments et des changements de prioritéDelivrer plus
  • ElisePrésentation, jeu et construction du flux, définition des différentes étapesLe lendemain c’est parti.A revoir sur la pres:Timing : Etape par étapeDéroulement : formalisation, …., jolie animation bien visuelle, montrant le déroulementMotivations : Volonté du manager, Equipe sceptique ?Timing: étape par étapeFomalisation du fluxDécorrélation des poker planningFin goal sprint + Allocation de % d’impedimentsPoker planning à la demandeAbandon de scrumC’est une transition non voulue – tres progressiveAu depart, on a eu besoin de formaliser notre flux car equipe distribuée => utilisation du kanbanpadEnsuite on a trouve les sprint planning trop longues et inproductive => séparation du poker planning - + tot que le sprint planning dans la semaineEnsuite on a eu de plus en plus de mal a trouve un goal de sprint a cause des yriades de petites taches => stop les goals de sprintEnsuite on avait beaucoup d’impediement on a alloué des % de sprint pour traiter les impediments => on a simplement pris en compte les gros sujetsEnsuite on a arrete les seances unique de poker planning – elles ont été mise au fil de la semaine au moment de l’arrivee des impedimentsOn a constaté qu’on s’était bien éloigné de scrum – on s’approchait de kanban – on a abandonne scrum et les sprints planning pour mettre en œuvre kanbanToute l’equipe était motivee pour changer le statut actuel et kanban satisfait la majorite
  • VeroPres outilsMontrer que les colonnes reflètent les spécialités
  • NicoColonne QA surchargee => mauvaise utilisation du WIPColonne tested & committed => formalisation du fluxCode reviewed=> notre flux evolue en fct de nos pratiques
  • Ce qui ne change pas pour les 3 :-Daily standupTravel :- Demo/retro régulière- Pas de planification , ni revue storiesBackend :-les démos sont réalisés à la demande-les retros sont régulières, environ tous les 15j ; mais autant que possible après une démo-à la demande aussi les backlogreview + poker planning, quand le PO en ressent le besoin pour sa priorisation, et/ou quand l’équipe va bientôt etre au chomage  Shopping :- Plus de démo- Rétro à peu près régulière- Scenarii / poker planning  
  • vero
  • NicoWip sous utilise : on pourrait limite producing pour se mobiliser en pairOn pourrait contraindre la colonne QA pour aider JM a faire la QA quand elle est saturee
  • eliseLes 3 équipes ont eu 3 expériences assez différentes du passage à Kanban. Néanmoins, Kanban a apporté un certains nombres d’avantages communs aux 3 équipes. Une tâche qui reste longtemps au même endroit, une colonne où s’accumulent des taches sont d’autant des indicateurs visuels d’un point bloquant.La visualisation des étapes de développement permet de ne pas oublier des taches : ex test fonctionnel, test de performance, documentation. Elle assure également un suivi de l’état de l’avancement de la story. Le travail des personnes spécialistes avec un rôle transversal comme QA ou production est intégré de manière plus fluide en kanban.En kanban, la priorisation des stories est plus souple. Il n’est pas la peine d’attendre la fin d’un sprint pour mettre une priorité haute à une nouvelle story.En kanban, fini la grosse journée de réunion enchainant demo, retro, backlogreview, poker planning et sprint planning. Ces réunions sont effectuées à la demande, plus souvent, et sont moins longues. On peut parler de dose homéopathique.
  • VeroniqueOrganisation à la demandeLe PO alimente en permanence le kanban – dispo pour repondre aux question de l’équipesle SM organise les reunions en permanence – contrainte de salle et de dispo des bonnes personnesKanbanWIP / velociteLe WIP et la vélocité ne s’utilise pas de la memefaconmoins de notion de predicatbilite en kanbanLes taches doivent etre petites pour etre comparablePlus complexe de remonter des alertes qu’avec un burndown: c’est l’acumulation de tache qui doit provoquer une alerteUtilisation de graph en nuage de pts complexite / tps de cycleEngagementPas d’engagement de l’équipe sur un goal – pas d’utilisation de la motivation collective a part pour faire sortir une tache rapidement du kanbanPas d’adrenaline de fin de sprintGestion du WIPLes stories n’ont plus vraiement d’instance obligatoire de revueUne story peut etredemarree sans revue 
  • Nico-> pas vraiment optimisation sur la quantité délivrée
  • Agile grenoble 2012scrum_kanban on_live_agile_grenoble

    1. 1. Avant la session … Avez-vous un point d’insatisfaction dans votre expérience de la méthode Scrum ? Si oui, notez le sur le post-it à votre disposition !Scrum à Kanban: 3 retours d’expériences
    2. 2. Scrum à Kanban:3 retours d’expériences Elise Vanholsbeeck / Véronique Mosnier / Nicolas Warzagier / 8 Novembre 2012
    3. 3. Qui sommes-nous? Véronique Elise Nicolas Travel Backend Shopping
    4. 4. Qui êtes-vous?
    5. 5. AgendaRappelsRetours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant?Bilan général
    6. 6. AgendaRappelsRetours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant?Bilan général
    7. 7. Rappels sur ScrumRappels
    8. 8. Rappels sur Kanban WIP Flux
    9. 9. Historique des méthodes dedéveloppement chez kelkoo Cycle en V Scrum Kanban 2007 2011Aujourd’hui:  4 équipes en Scrum  3 équipes en Kanban
    10. 10. AgendaRappelsRetours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant?Bilan général
    11. 11. 3 équipes – 3 profils Travel Backend ShoppingEffectif 4 développeurs 4 développeurs 7 développeurs 1 QA 1 PO 1 QA 1 PO 0 SM 1 PO 1 SM 1 SMLocalisation Grenoble - Londres Grenoble Grenoble - LondresSpécialisation Oui Non NonÉquipe dédiée 50% 100% 80%Type de projet Stabilisation Maintenance AméliorationVisibilité du produit Moyenne Basse HauteRythme des releases 1 semaine 2 semaines 1 semaineMaîtrise de Scrum Débutante Experte Moyenne
    12. 12. AgendaRappelsRetours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant?Bilan général
    13. 13. Les raisons du changementQuels sont les points d’insatisfaction rencontrés avecla méthode Scrum? Partage du Impédiments: Definition of Done Site instable Routine Temps passé en Manque de cérémonials visibilité sur le Envie d’améliorer travail de chacun la productivité
    14. 14. AgendaRappelsRetours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant?Bilan général
    15. 15. La transition Travel Backend ShoppingMotivation Toute l’équipe Volonté du manager Toute l’équipe mais Équipe curieuse diluéePréparation Inspiré de shopping Formation sur une journée AucuneDéroulement Big Bang One Shot En douceur ? Impediments Goal du Sprint Sprint + formalisation du flux Sprint Planning
    16. 16. AgendaRappelsRetours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant?Bilan général
    17. 17. Kanban Travel
    18. 18. Kanban Backend Definition of Done Definition of Done de chaque colonne de chaque colonne WIP WIP WIP
    19. 19. Kanban Shopping Une colonne Une colonne « pense-bête » surchargée ! Une colonne optionnelle
    20. 20. Cérémonies d’équipes Travel Backend ShoppingStand-upDemoRetroPoker planningScenarii /Backlog review N/A Abandonné Régulier Journalier À la demande
    21. 21. AgendaRappelsRetours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant?Bilan général
    22. 22. Conclusion Travel Visualisation du flux Capacité à faire de la QA Incapacité à évaluer les tâches avant
    23. 23. Conclusion Backend Sortir de la routine Productivité identique Métriques mal exploitées
    24. 24. Conclusion Shopping Intégration des imprévus au flux Flux formalisé et évolutif Mauvais usage du WIP
    25. 25. AgendaRappelsRetours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant?Bilan général
    26. 26. Avantages• Visualisation  Étapes de développement  Bloqueurs  Spécialisations• Souplesse  Gestion de la priorisation des stories  Répartition du temps en réunion
    27. 27. Inconvénients• Organisation à la demande  Travail constant du PO et du Scrum Master  Mauvaise compréhension des Stories• Reporting  Métriques différentes de Scrum  Manque d’engagement de l’équipe• Gestion du WIP difficile
    28. 28. Ce qui ne change pas• Les rôles et le Product Backlog• La productivité  Temps de développement équivalent  Temps total passé en réunion• L’effort sur la qualité des User Stories  Critères d’acceptance  Estimations
    29. 29. Référence Disponible gratuitement http://www.infoq.com/minibooks/kanban-scrum-minibookKanban and Scrum: making the most of bothHenrik Kniberg & Mattias Skarin
    30. 30. L’essentielFormaliser le flux et limiter le WIPConserver les bonnes pratiques de ScrumPas de recette miracle – chacun implémente à son rythme et comme il veut

    ×